Настройка среды. "Голый" бинарник, или Исполняемый файл без main()

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

Оригинал блога разрабатывается на GitHub. Замечания к оригиналу оставляйте на странице Issues репозитория выше, а к переводу в личке, комментариях или тут. Код, написанный в этой статье, содержится в ветке post-01.

Вступление

Для того, чтобы написать свою ОС, нам нужен код, не зависящий от библиотек или функций другой операционной системы. Это значит, что мы не можем использовать потоки исполнения (threads), файлы, память в куче (heap), сеть, вывод в терминал и так далее. Но это можно преодолеть, написав свою ОС и драйвера.

Мы не можем использовать большую часть стандартной библиотеки Rust, но также есть много функций, которые мы можем использовать. Например итераторы, замыкания, сопоставление с образцом, Option и Result, форматирование строк, и конечно же, концепцию владения. Это позволит написать своё ядро в высокоуровневом стиле, не заботясь о неопределённом поведении или безопасности памяти.

Эта статья рассказывает, как создать автономный исполняемый файл и почему это необходимо. Если нужен только пример, можно прокрутить до части "Заключение".

Отключение стандартной библиотеки

По умолчанию скомпилированный код собирается с участием стандартной библиотеки, которой нужна ОС для реализации таких функций, как файлы, сеть и т.д. Также она зависит от стандартной библиотеки С: libc, которая еще больше использует фичи ОС. А так как мы пишем программу, которая заместит собой обычную ОС, это нам не подходит. Нужно отключить библиотеки с помощью no_std.

Сначала создадим проект с помощью Cargo. Это делается с помощью коммандной строки:

cargo new os-in-rust --bin --edition 2018

Я назвал проект os-in-rust (для избегания путаницы с оригинальным блогом), но можно выбрать любое имя. Флаг --bin говорит, что нужен проект, который будет собираться в исполняемый файл, а не в библиотеку. --edition 2018 значит, что нужно использовать именно редакцию Rust 2018. Cargo сгенерирует такую структуру папок:

os-in-rust Cargo.toml src     main.rs

Файл Cargo.toml содержит конфигурацию: название проекта, автор, версию и зависимости. В src/main.rs содержится код, который выполнится, когда мы запустим скомпилированный бинарник. Компилируется он коммандой cargo build, а исполняемый файл будет в папке target/debug.

Атрибут no_std

Сейчас код собирается с использованием стандартной библиотеки. Это поведение можно выключить с помощью атрибута no_std:

// main.rs#![no_std]fn main() {  println!("Hello, world!");}

Если попробовать собрать проект, получим ошибку:

error: cannot find macro `println!` in this scope --> src/main.rs:4:5  |4 |     println!("Hello, world!");  |     ^^^^^^^

Причиной этому является тот факт, что макрос println часть библиотеки Rust, которую мы больше не используем. Получается, мы не можем ничего выводить. Это имеет смысл, так как для вывода нужна консоль или файл, а для них нужна запущенная ОС. :(

Так что удалим вывод и снова попробуем запустить сборку:

// main.rs#![no_std]fn main() {}

> cargo builderror: `#[panic_handler]` function required, but not founderror: language item required, but not found: `eh_personality`

Реализация panic!()

Атрибут panic_handler говорит языку, что эту функцию нужно вызвать, если произошла паника (вызов panic!()). В стандартных библиотеках она есть, но в среде no_std надо ёё создать самим:

// main.rs#[panic_handler]fn panic(_info: &PanicInfo) -> ! {  loop {}}

В параметре PanicInfo содержится файл и номер строки, где код запаниковал, а также (опциональное) сообщение об ошибке. Эта функция не должна возвращать выполнение другой, поэтому тип возвращаемого значения ! (never). Сейчас она ничего не делает, а просто устраивает бесконечный цикл.

eh_personality

eh_personality это "элемент языка", функция или тип, которые необходимы для работы компилятора. Например, типаж Copy элемент языка, который говорит компилятору, какие типы поддерживают семантику копирования. Если посмотреть на его реализацию, можно увидеть аттрибут #[lang = "copy"], который определяет этот типаж как элемент языка.

Вообще, можно попробовать создать свою реализацию элементов языка, это нужно использовать только в крайнем случае, потому, что они очень часто меняются и даже не имеют проверки типов! Хорошо, что есть еще один способ.

Элемент языка eh_personality помечает функцию, которая используется для реализации "разматывания" стека вызовов. По умолчанию Rust использует это для вызова деструкторов всех переменных на стеке в случае паники, чтобы освободить всю использованную память. Но это сложный процесс, которому требуются библиотеки, специфические для каждой ОС (libunwind на Linux и структурированная обработка исключений на Windows), то мы не будем это использовать.

Выключение разматывания

Rust дает возможность просто прерывать исполнение программы в случае паники. Это также исключает необходимые для разматывания данные, уменьшая бинарник. Есть несколько мест, где можно это выключить. Самое простое Cargo.toml:

[profile.dev]panic = "abort"[profile.release]panic = "abort"

Это устанавливает стратегию обработки паники в значение abort и для профиля dev (используется при вызове cargo build), и для профиля release (cargo build --release). Теперь нам не нужен eh_personality.

Мы пофиксили обе ошибки. Но теперь есть новая:

> cargo builderror: requires `start` lang_item

Атрибут start

Можно подумать, что функция main вызывается первой при исполнении программы. Но это не так для большинства языков. Много языков программирования имеют свою среду исполнения, которая отвечает за сборку мусора (Java, C#, JavaScript...) или программных потоков исполнения (корутины, горутины в Go). Эту среду нужно инициализировать перед вызовом main с очевидных причин.

В типичном исполняемом файле Rust исполнение начинается в библиотеке, которая называется crt0, что настраивает среду для исполнения кода на С. Это, между прочего, включает в себя создание стека и положить параметры в правильные регистры. Потом среда С вызывает среду Rust в месте, позначенном элементом языка start, Rust инициализируется, и только потом вызывает main().

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

Переопределение точки входа

Чтобы сказать компилятору, что мы не используем обычную цепочку вызовов при инициализации, надо добавить атрибут #![no_main].

#![no_std]#![no_main]use core::panic::PanicInfo;#[panic_handler]fn panic(_info: &PanicInfo) -> ! {    loop {}}

Мы удалили функцию main(), так как она все равно не вызывается. Вместо нее надо определить функцию _start:

#[no_magnle]pub extern "C" fn _start() -> ! {  loop {}}

Используя атрибут #[no_mangle], мы выключаем искажение имен, чтобы компилятор назвал функцию _start, а не, например, _ZN3blog_os4_start7hb173fedf945531caE. Это используется компилятором для того, чтобы избежать ошибок переопределения.

Также надо пометить функцию extern "C", это говорит компилятору, что функцию надо вызывать с помощью конвенции С, а не Rust (которая еще и изменяться, видно, может, так как по ней нету документации). Название такое в функции потому, что это название точки входа по умолчанию на большинстве систем.

Вы, наверное, заметили, что она возвращает !, то есть, не заканчивает свое исполнение. Это нужно потому, что эту функцию будет вызывать загрузчик, а если она завершится, то ПК выключится (или перезагрузится).

Теперь, если сделать cargo build, мы получим ошибку сборщика.

Ошибки сборщика

Сборщик это программа, которая собирает ваш код и библиотеки, которые ему нужны, в единое целое. А так как разные системы имеют свои форматы исполняемых файлов, они имеют свои сборщики, и разные ошибки.

Надо сделать так, чтобы они не появлялись, нужно сказать сборщику, что мы не используем стандартные библиотеки. Это можно сделать 2 способами: передавая сборщику параметры, или созданием конфигурации целевой платформы.

Сборка для "железа"

По умолчанию Rust пробует создать исполняемый файл для вашей платформы. Если вы используете Windows на x86-64, Rust создаст .exe с инструкциями для архитектуры x86-64. Это называется целевая платформа.

Для различания платформ Rust (да и многие другие инструменты) использует target triples. Чтобы увидеть эту строку для вашего ПК, надо выполнить rustc --version --verbose:

rustc 1.47.0-nightly (576d27c5a 2020-08-12)binary: rustccommit-hash: 576d27c5a6c80cd39ef57d7398831d8e177573cccommit-date: 2020-08-12host: x86_64-unknown-linux-gnurelease: 1.47.0-nightlyLLVM version: 10.0

Это вывела данная комманда на моей системе (Linux x86-64). Параметр, который нас интересует host, там пишет, что:

• система на базе x86-64,
• ОС: Linux,
• ABI: GNU

Компилируя для такой платформы, Rust думает, что бинарник будет исполняться на какой-нить операционной системе (в моем случае, Linux) и использует системные библиотеки (libc, libunwind и другие). Чтобы не было ошибок сборщика, надо компилировать под другую целевую платформу.

Примером такой платформы является thumbv7em-none-eabihf, что означает встраиваемая система на базе ARM. Детали нас не интересуют, главное то, что там нет ОС (none). Чтобы иметь возможность компиляции под данную платформу, надо добавить ёё с помощью Rustup:

rustup target add thumbv7em-none-eabihf

Теперь можно скомпилировать код:

cargo build --target thumbv7em-none-eabihf

Используя флаг --target, мы кросс-компилируем код для другой платформы. Так как написано, что нету операционной системы, сборщик даже не пробует найти библиотеки.

Это тот способ, который мы будем использовать. Но вместо thumbv7em-none-eabihf мы создадим кастомное описание платформы для x86-64. Детали будут в следующей статье (которую я пока не перевел), а пока можно почитать оригинал. Если не ошибаюсь, эти статьи также переводил m1rko, но не могу найти эту (да и любую).

Заключение

Код для минимального бинарника, что запустится на голом железе выглядит так:

src/main.rs:

#![no_std] // don't link the Rust standard library#![no_main] // disable all Rust-level entry pointsuse core::panic::PanicInfo;#[no_mangle] // don't mangle the name of this functionpub extern "C" fn _start() -> ! {  // this function is the entry point, since the linker looks for a function  // named `_start` by default  loop {}}/// This function is called on panic.#[panic_handler]fn panic(_info: &PanicInfo) -> ! {  loop {}}

Cargo.toml:

[package]name = "crate_name"version = "0.1.0"authors = ["Author Name <author@example.com>"]# the profile used for `cargo build`[profile.dev]panic = "abort" # disable stack unwinding on panic# the profile used for `cargo build --release`[profile.release]panic = "abort" # disable stack unwinding on panic

Для сборки эта комманда:

cargo build --target thumbv7em-none-eabihf

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

Привет Хабр! Меня зовут Ильдар. Хочу поделиться с сообществом своими идеями разработки Облачной ОС.

Начну с рассказа простого кейса, почему я начал задумываться о создании Облачной ОС. В прошлом году я решал бизнес задачи по настройке CRM+телефония+сайт+почта+вебинары+email рассылка. Решение есть, оно настраиваемое и рабочее. Но есть нюансы, которые я заметил в процессе настройки.

Первый нюанс, в том что, я получил рабочую систему, в мультисервисах в мультиокнах. Т.е. чтобы с ней работать, нужно заходить в разные системы по разным url адресам и менять везде настройки. К примеру, чтобы добавить сотрудника, нужно добавить его в CRM, затем в телефонию, затем создать почту, затем добавить интеграцию почты в срм. Очень много действий, по созданию и удалению пользователя. Особенно, когда пользователей много. Легко запутаться, и что-то забыть.

Второй нюанс в том, что клиент (юр лицо) платил этим системам по Visa карте, и нет никакой возможности платить как юр лицо. Вообще мне непонятно, зачем разрабатывать системы для юр лиц и делать только Visa/Mastercard платежи, которые предназначены для физ лиц, а не для юр лиц. А как компании должны отчитываться по бухгалтерии? Я знаю, что некоторые системы работают с юр лицами, но только со своей страны. А если юр лицо из другой страны? Что делать в этом случае? Самое странное, это то, что нужно помнить о том, когда в каких сервисах истекает тот или иной платеж. Если сервис один, то все просто. А если их 10, или 20? А как мне выставить единый счет и просто его оплатить?

В третьих сбои. Так как система мультисервисная, то возрастает количество сервисов, возрастает и риск сбоя всей системы. Получалось так. В один день висит CRM на пол дня, в другой день зависает телефония. За месяц сервисы зависают по одному-двум раз каждый, но так как сервисов много, то получается, что вся система виснет в месяц более 5 дней, стабильно раз в неделю, а это убытки, т.к. менеджеры не работают, продажи не идут. Работать при этом, становиться невозможно.

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

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

И самый интересный момент. А как мне эти сервисы запустить на своем сервере? Т.е. арендовать сервер на доверенном хостинге, и там настроить всю систему? А никак, это же SaaS и вендорлок.

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

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

Об этих проблемах я и задумался. Хочется одно окно, единый url адрес, по которому можно будет пользоваться системой. Так у меня появилась идея создания Облачной Операционной Системы.

Описание Облачной ОС

Скажу сразу. Я ее создал. Называется она BAYRELL Cloud OS и сейчас находится в альфа версии 0.1. Она OpenSource. Инструкция по установке здесь. Скажу сразу это альфа версия, и многое я в ней еще не сделал. Я планирую выпуск версии 0.2, который будет более проработан. Список изменений, того что будет в версии 0.2 здесь на гитхабе.

Суть Облачной ОС очень проста. Это технология запуска кроссплатформенных облачных IT сервисов и облачного ПО в единой системе. В едином окне. Под единым окном я понимаю один url адрес, логин и пароль, по которому обращается клиент, чтобы получить доступ ко всей интранет системе с установленным туда софтом. Для клиента это удобно. Одно окно, один логин и пароль. Всё, что нужно для работы там.

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

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

В отличие от привычных традиционных операционных систем, данная ОС облачная. Т.е. устанавливается не на локальные компьютеры, а устанавливается в облако или на сервера и делает из них облачный кластер. И соответственно если, разные IT компании, будут разрабатывать софт, под эту систему, то получится использовать и интегрировать их наработки в единой системе, в одном окне. А не так, как сейчас, с SaaS решениями, где нужно заходить в кучу разных систем, чтобы работать с ними.

Вторая важная функция в том, что ОС дает возможность устанавливать программы в один клик. Упрощает процесс настройки софта. Вспомните те простыни мануалов, которые нужно читать, чтобы поднять или настроить сервер, nginx, почту и т.п. А если сделать возможность установить софт в одну кнопку? Ведь это же здорово, и самое главное возможно. Нажал кнопку, софт установился. В интерфейсе можно мышкой поменять настройки. Это значительно упрощает управление сервером.

Я знаю многие скажут консоль наше все. Я тоже люблю консоль. Но наступили те времена, когда в голове нужно держать кучу команд и параметров к ним. И это проблема. Я открыл мануал к nftables и сразу же закрыл. Потому что теперь нужно учить еще и те команды. Мало того что iptables сложный, так они еще сложнее сделали. Уже недостаточно знать команды man, ls, mkdir и т.п. Сейчас нужно управлять Docker, кубернетос кластерами и прочими системами, network manager для сети и т.п. Количество команд, которые нужно помнить возрастает с каждым годом, и проще не становиться. А зачем тогда IT системы, если они усложняют жизнь, а не упрощают их. Ведь хочется иметь систему с простым логичным интерфейсом, или, например, админить систему с телефона.

Роль контейнеров

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

Я сделал веб интерфейс для управление кластером. Самим кластером управляет Docker Swarm, а веб интерфейс управляет Docker swarm'ом. Пока интерфейс простенький и к сожалению, еще не удалось избежать ввода консольных команд, но думаю в версии 0.2, я сделаю более удобным веб интерфейс инсталлятора и настройку кластера.

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

• Модель слоев и виртуальных пространств.
• Запуск софта в кластере.
• HTTP маршрутизация через nginx. Обновление маршрутизации через интерфейс.
• Авторизация пользователей.
• Разработал софт, планировщик задач, для примера.

Модель Облачной ОС

В Облачной ОС есть два важных понятия. Это виртуальные пространства и слои данных.

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

Знаете почему Shared хостинги дешевле чем VPS? Потому что они делят одни ресурсы одного сервера между собой, а VPS по сути запускает отдельную виртуальную машину. Вот и получается, что на одном сервере VPS можно запустить 10-20 инстансов, а хостинг может обслуживать тысячи клиентов на одном сервере.

Но данные клиентов нужно как-то разделить между собой. Это решается с помощью концепции виртуальных пространств и слоев данных.

Проще показать на схеме. Каждая служба это Docker service. В конфиге службы указываются параметры подключения к базе данных. База данных делится на слои данных.

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

У каждого слоя есть идентификатор UID и URL адрес, по которому он доступен. UID имеет вид cloud_os.test:layer_0. cloud_os.test это название пространства, layer_0 номер слоя. UID может быть одинаковым у слоев для разных служб. Одинаковый UID нужен, чтобы упростить настройку обмена данными между службами. По умолчанию, служба просто будет отправлять запрос в другую службу с текущим layer_uid.

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

Когда запрос приходит в службу получателя по системной шине, эта служба смотрит есть ли такой ключ подписи у пары layer_uid, space_id, которые были указаны в запросе. Если находит, то проверяет подпись. Если подпись неверна, то отклоняет запрос. Это нужно, чтобы сделать изоляцию виртуальных пространств между собой. Но если нужно сделать обмен данными между несколькими пространствами, то в них нужно добавить слои служб с одинаковыми UID.

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

Бизнес модель

Как это все использовать, и как зарабатывать деньги?

Имхо, я думаю одним из причин, почему линукс не популярен среди десктоп, является то, что он бесплатный. Забавно, но это так. Сейчас объясню. Причина в наличии качественного софта.

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

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

А что даст инвестирование в десктоп? За операционную систему платит конечный потребитель, а не компания разработчик софта. Разработчики софта, в основном, пишут свой софт под ту ОС, которая популярна на данный момент, потому что они смогут больше заработать, на количестве установок. А инвестирование в линукс не даст прибыли разработчикам софта для десктопа.

Линукс бесплатный. У него нет продаж, значит инвестировать разработку с продаж не получится. В итоге это влияет на скорость написания качественного софта. Процесс идет медленно, потому чтобы сделать качественный софт, нужны специалисты, а им нужно платить зарплату. А Windows инвестирует в разработку с продаж, это дает возможность больше нанять специалистов и быстрее разрабатывать софт, сделать его удобнее для пользователя. А чем удобнее для пользователя, тем больше будут пользоваться, тем еще больше софта будет написано под эту систему. Вот поэтому Windows популярнее линукса на десктоп.

Хотя сейчас ситуация потихоньку меняется. С юзабилити и качественным софтом в линуксе дела обстоят гораздо лучше, чем было раньше. Я с 2016 года пользуюсь линуксом на десктопе. Но есть все же моменты, которые хочется исправить и доработать. Например, CorelDraw не поставить на линукс. И мне, чтобы использовать банк клиент, нужно использовать Windows систему, потому что на линуксе банк клиент не работает.

Чтобы сделать линукс популярным, нужен качественный софт под него, которым будут пользоваться люди. А также система доставки и магазин приложений. Я благодарен компании Steam, которая сделала для линукса клиент, и игры теперь работают на линуксе. Те игры, которые не поддерживают линукс, запускаются благодаря технологии Valve Proton.

Я считаю, линукс хорошей системой для IT программистов, которые делают интернет сервисы. Потому что софт, которые программисты пишут, будет работать под линуксом на сервере. И гораздо лучше писать софт в родной системе, нежели использовать сборки типо Denwer или cygwin. Именно по этой причине я поставил Ubuntu. Потому что нужно было работать с докер, lxc, iptables, php, python, nodejs, npm и прочими штуками. А запускать постоянно виртуальную машину с линкусом в Windows, чтобы пользоваться этими инструментами, как то это неправильно. А cygwin и msys2 давно перестали справляться с теми задачами, которые мне нужны.

Я сам подумываю о сборке десктоп версии на базе openbox с контейнерами. Контейнеры, либо flatpak, либо что-то новое. чтобы упростить процесс доставки приложений. Также хорошо разработать для линукса маркет приложений, чтобы дать разработчикам возможность заработка. Вот тогда линукс начнет заходить в массы. Может быть я это сделаю в рамках разработки облачной ОС. Пока сложно сказать.

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

Для разработки Облачной ОС тоже нужны ресурсы. А чтобы ресурсы получить, нужно понимать как зарабатывать. А варианты заработка есть. Я представляю бизнес модель.

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

Клиент же сам может решить: приобрести сборку у облачных интеграторов, либо напрямую купить решения у вендора и тем самым собрать свою сборку. Но скорее всего, выгоднее будет брать решения у облачных интеграторов, потому что оно будет комплексным, разработанное и адаптированное под нишу клиента. А времени самостоятельно собирать сборку у клиента может не быть. Ему нужно решения для бизнеса, для его ниши, как можно быстрее и удобнее.

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

Бизнес выгода облачных интеграторов в том, что они не занимаются разработкой софта. Они берут лицензии на софт у вендоров по оптовым ценам и делают сборку. Каждая продажа конечной сборки окупает затраты на покупку лицензии. Для облачных интеграторов не нужно нести затраты на разработку своего софта, когда есть готовый. По скромным оценкам, чтобы разработать простой сервис, нужно для начала 50 000$. А если для сборки нужно 10 таких сервисов? Выходит приличная сумма. Гораздо логичнее найти компании, которые будут заниматься разработкой софта и купить у них лицензии или взять в аренду, что еще дешевле.

Интерес же вендоров, продать как можно больше количество лицензий. Они заинтересованы в том, чтобы работать как можно с большим количеством облачных интеграторов. Больше облачных интеграторов больше продаж.

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

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

Поясню на примере. Чтобы произвести 100 экземпляров IT продукта, нужно затратить 0. Чтобы произвести 10 000 экземпляров IT продукта, тоже нужно затратить 0. В этом весь феномен. Хотя, скорее всего, там есть какие-то затраты, в виде стоимости интернета, электричества или объема трафика, которое затрачивается, чтобы скачать файл. Но они настолько малы. И я даже не знаю как это посчитать, и нужно ли вообще это считать. А вот если вы записываете свой софт на CD диск, то да затраты на производство будут. Но кто в 2020м записывает что-то на CD диск, для того чтобы распространить софт, когда есть гитхаб и докерхаб?

Затраты есть другие. Они идут, чтобы продать товар: реклама, оплата менеджерам по продажам. Или же, чтобы разработать новую версию продукта. Но они не относятся именно к производству экземпляра IT продукта.

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

Для клиента, конечного потребителя, преимущества будут следующие:

1. Получает систему, которая работает в едином окне.
2. Получает возможность устанавливать софт в один клик.
3. Доступные цены для клиента.
4. Может создавать бэкапы и холодные резервные копии системы.
5. Отсутствует вендорлок, клиент может запустить софт на своих серверах.
6. За софт клиент будет платить в единое окно. При этом, в каждом регионе для юр лиц будут свои облачные интеграторы, которые будут предоставлять клиентам бухгалтерские документы.
7. Также облачный интегратор, обеспечивает внедрение, тех поддержку. И ему можно всегда позвонить, либо их человек подъедет в офис и настроит, что не работает. Это удобно, и иногда очень не хватает, если работать с SaaS решениями.

Рынки

Есть два огромных рынка, где может применяться данная модель. Это рынок интранет систем для бизнес задач, и рынок IoT систем для умного дома. Причина, по которой рынок IoT систем, пока странно развивается, в том, что нет маркета приложений и операционной системы для IoT.

Роль Облачной ОС

Схема красивая. Но возникает вопрос? А как разные вендоры должны разрабатывать софт, таким образом, чтобы он нормально работал друг с другом? И как облачные интеграторы будут собирать сборку? А вот для этого и нужна облачная операционная система. Она задает фундаментальный стандарт, как должен работать софт, чтобы его запустить интегрированно друг с другом.

Текущая ситуация в том, что сейчас все вендоры хотят разработать свой SaaS, и получается, то о чем я говорил в начале, мультисервисная проблема. Мало того, что сервисов становится много и клиентам сложно и неудобно, так сами вендоры, при разработки SaaS решения несут лишние издержки, такие как:

• содержание технической поддержки;
• обслуживание серверов;
• содержание отдела продаж.

Имхо, но это все можно делегировать облачным интеграторам. Вендоры должны сделать облачный софт и адаптировать его под ОС, а облачные интеграторы, создадут из этого софта сборку и будут заниматься продажами, тех поддержкой, внедрением, обслуживанием и даже хостингом. Сейчас они поступают так: делают сборку SaaS решений, обеспечивают продажи и тех поддержку. Но становится две тех поддержки, и по сути облачный интегратор, просто передает запросы от клиента сервису, и ждет пока SaaS сервис ему ответит. А я считаю, что облачный интегратор, сам должен решать вопрос и исправлять проблему, а не ждать у моря погоды, когда ответит ему SaaS.

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

Я считаю, что умный дом должен построен по следующей схеме. Есть IoT ОС, которая ставится на распу. Это распа и все устройства умного дома подключаются к одной сети по wi-fi или по bluetooth. А приложения для управления устройствами умного домом ставятся в IoT ОС, например, скачиваются с маркета приложений, с сайта производителя устройства или с докер хаба. Мобильное приложение оно одно, от управления этой ОС. Зайдя в мобильное приложение, открывается доступ ко всему софту и всем устройствам подключенных к умному дому. И сама ОС, управляет умными домом по тем алгоритмам, которые заложены в приложении.

Подытожем и поговорим, немного, об играх

Почему я так уверен в успехе? Все очень просто. Есть довольно интересный опыт в сфере игровой индустрии.

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

Во вторых стоит отметить две игры Dwarf Fortress и RimWorld.

Dwarf Fortress это игра, пример вечной разработки, когда разработчики хотят своими силами разработать целиком всю игру. В итоге игра находиться в альфе и долго разрабатывается (с 2002 года, а уже 2020). 18 лет разработки и нет релиза, это никуда не годится.

RimWorld это игра вдохновленная идеями Dwarf Fortress. Там не стояла задача разработать все на свете, и ванильная версия игры довольно скромная. Но что очень сильно меня удивило, это то, что сообщество создало очень большое количество модов, которые доводят игру до логического уровня, как должно работать на самом деле. Самый интересный модпак, это сборка HardCore SK. Они собрали моды, и сделали между ними баланс. Это позволило создать совершенно другую игру, которая отличается от ванильной, и я думаю, такой как раз таки и должен быть настоящий RimWorld. Ребята просто молодцы! И это работает со стим версией.

Именно тот факт, что разработчики RimWorld позволили создавать плагины для их игры, получился шедевр в виде сборки HardCore SK.

По сути, те кто создал сборку HSK сделали интеграцию игры и готовых модов, то что я и говорил про облачных интеграторов. Они даже не разрабатывали все эти моды. Облачные интеграторы также делают интеграции, но делают это для IT систем, бизнеса и IoT рынка.

Из этого я сделал очень важный вывод. Очень сложно самому, одной компании разработать мега супер пупер крутой вундер сервис, в котором будет всё, и все клиенты будут использовать только его. Если это и возможно, то это будет очень долго, дорого и в далеком будущем. Логичнее построить инфраструктуру, где другие люди и компании смогут не только разработать большое количество разного софта, под разнообразные задачи, но так же и зарабатывать на этом. И причем, это будет на порядки быстрее. Единственное что нужно для этого, это операционная система (ядро), которая будет задавать фундаментальный стандарт, как софт должен работать друг с другом, и решать принципиальные важные вопросы по авторизации, безопасности, обмене данными между сервисами и т.п.

Я сейчас собираю команду. Если есть желание присоединиться или инвестировать в проект, то пишите в личку.

Также буду признательным, если вы подпишетесь на сообщество вк, фб, инстаграм, или посетите мой сайт.

Публикую инструкцию по установке облачной ОС версии 0.1 на Raspberry Pi и ссылку на пост, о том, как я разработал язык программирования. Кстати сама ОС написана на нем :).

Язык программирования сейчас представляет собой единую фуллстек технологию для разработки сайтов и облачных IT систем. Его преимущество в том, что он транслируется сразу в js и php. И он функциональный. В нем из коробки работают неизменяемые структуры данных. При этом можно писать в функциональном стиле или по старинке в ООП. Есть server side render для бэкенд и client render для фронтенд. Но самое главное преимущество, в том, что это единая технология, на котором можно написать фронтенд и бэкенд. И не нужно заводить зоопарк на nodejs. Я вообще хочу отказаться от nodejs в пользу python или llvm + webassembly с компиляцией. Т.е программа пишется на одном языке и компилируется через llvm для бэкенд, и через webassembly для фронтенд. Но это будущее :).

Буду признателен, если вы поставите звездочки на проекты:

• Язык программирования BAYRELL Language
• Облачная операционная система BAYRELL Cloud OS

Также я думаю открыть школу по программированию. Если кто хочет поднять свои скилы в IT, тоже пишите в личку.

Мы продолжаем разбираться как работает ПК на примере клавиатуры и Windows 10. В этой статье поговорим о том как происходит единение софта и железа.

Старт системы

Полностью компьютер выключен когда он отключен от питания и конденсаторы на материнской плате разрядились. До эры смартфонов мобильные телефоны часто глючили и если перезагрузка не лечила проблему, то приходилось доставать батарею и ждать 10 секунд, потому что сбрасывалось программное состояние ОС, в то время как чипы на материнской плате и контроллеры устройств оставались активными сохраняя состояние, драйвера ОС к ним просто реконнектились. 10 секунд время на разрядку конденсаторов, состояние чипов сбрасывается только при полном отключении.
Если же ПК подключен к розетке или батарее, то он находится в режиме Stand-By, это значит что по шине питания подаётся маленькое напряжения (5В) от которого запитываются некоторые чипы на материнке. Как минимум это системный контроллер, по сути это мини-компьютер запускающий большой компьютер. Получив уведомление о нажатии кнопки Power он просит блок питания/батарею подать больше напряжения и после инициализирует весь чип-сет, в том числе и процессор. Инициализация включает в себя перекачку кода и данных прошивки материнки (BIOS/UEFI) в оперативную память и настройку CPU на её исполнение.
Думать что кнопка Power это рубильник который подаёт электричество на CPU и тот начинает исполнять с заранее известного адреса прошивку BIOS неправильно. Возможно старые компьютеры так и работали. Кнопка включения находится на своей плате, вместе со светодиодами состояний и к материнке она подключается через специальный разъём. На картинке ниже видны контакты для кнопки Power, Reset, а также светодиодов с состоянием Power и чтения жёсткого диска. Нажатие кнопки включения переводится в сигнал на контакты материнки, откуда он достигает системный контроллер.


Контакты на материнке для подключения кнопки включения, светодиодов состояния Power, жёсткого диска и динамиков.


Плата ноутбука с кнопкой включения и светодиодом состояния

Cистемный контроллер обладает огромными полномочиями включать и выключать компьютер, исполнять код в режиме ядра. Помимо него могут быть и другие чипы со сравнимыми возможностями, такие как Intel Management Engine или AMD Secure Technology (часть CPU), которые так же работают когда компьютер выключен. Чип с Intel ME имеет в себе x86 CPU с операционной системой MINIX 3. Что он может делать:

1. Включать и выключать компьютер, т.е. выполнять программы имея доступ ко всей вычислительной мощности, периферии машины и сети.
2. Обходить ограничения файервола.
3. Видеть все данные в CPU и RAM, что даёт доступ к запароленным файлам.
4. Красть ключи шифрования и получать доступ к паролям
5. Логировать нажатия клавиш и движения мыши
6. Видеть что отображается на экране
7. Вредоносный код в Intel ME не может быть детектирован антивирусом, потому как на такой низкий уровень он добраться не может
8. И конечно же скрытно отправлять данные по сети используя свой стек для работы с сетью.

Это вызывает серьёзные вопросы безопасности, потому как он может быть хакнут или использовать в шпионских целях.

Если вы задумаете установить мощную видеокарту (Nvidia 2070 S) на офисный ПК, то просто вставить её недостаточно, потому как она требует питание в 600W, в то время как такой ПК имеет блок на ~500W. Первое что придёт в голову купить новый блок питания на 650W с отдельной линией для видеокарты. Но и здесь будут разочарования, потому как разъёмы материнки будут не совпадать с разъёмами БП, а если его отдельно воткнуть в розетку и подключить к видюхе тоже ничего не будет в блоке питания вентилятор не крутится и изображения нет. Так происходит, потому что БП должен получить сигнал от материнки на полное включение. Очевидное решение новая материнка с совместимыми разъёмами, однако она стоит ~$300. Есть решение проще, хоть оно и вызывает опасения пожаробезопасности. Берём скрепку, разгибаем и вставляем в зелёный (PS_ON) и один из чёрных пинов (COM). Теперь всё должно работать.

Поиск загрузчика ОС

Есть два вида прошивки материнки BIOS (Basic Input Output System) на старых машинах и UEFI (Unified Extensible Firmware Interface) на новых. Windows 10 поддерживает обе и абстрагирует различия между ними. UEFI правильней называть ОС чем прошивкой, потому как он предлагает больше возможностей, к примеру богатый графический интерфейс вместо текстового, наличие мышки, больший объём доступной памяти, улучшенная модель безопасности и валидации файлов ОС, взаимодействие с железом через API, вместо прерываний как в BIOS.


Пример экрана монитора BIOS.

Программа BIOS хранится на отдельном чипе, подключенном к Южному мосту. Этот чип можно достать и перепрошить новой программой, по факту это просто носитель памяти, а не самостоятельный микрокомпьютер.


Настройки BIOS (системное время, например), хранятся на другом чипе который как правило находится возле круглой батарейки, которая на самом деле является литиевым аккумулятором, подзаряжающимся во время работы ПК. Называется он CMOS, что означает Complementary Metal Oxide Semiconductor, а по-русски просто КМОП, что есть комплементарная структура металл-оксид-полупроводник.


Первым делом программа BIOS выполняет проверку подсистем, эта процедура называется POST Power On Self Test. Тест может быть сокращённый либо полный, это задаётся в настройках BIOS. Процитирую Википедию, что в себя включают эти тесты:
Сокращённый тест включает:

1. Проверку целостности программ BIOS в ПЗУ, используя контрольную сумму.
2. Обнаружение и инициализацию основных контроллеров, системных шин и подключённых устройств (графического адаптера, контроллеров дисководов и т. п.), а также выполнение программ, входящих в BIOS устройств и обеспечивающих их самоинициализацию.
3. Определение размера оперативной памяти и тестирования первого сегмента (64 килобайт).

Полный регламент работы POST:

1. Проверка всех регистров процессора;
2. Проверка контрольной суммы ПЗУ;
3. Проверка системного таймера и порта звуковой сигнализации (для IBM PC ИМС i8253 или аналог);
4. Тест контроллера прямого доступа к памяти;
5. Тест регенератора оперативной памяти;
6. Тест нижней области ОЗУ для проецирования резидентных программ в BIOS;
7. Загрузка резидентных программ;
8. Тест стандартного графического адаптера (VGA или PCI-E);
9. Тест оперативной памяти;
10. Тест основных устройств ввода (НЕ манипуляторов);
11. Тест CMOS
12. Тест основных портов LPT/COM;
13. Тест накопителей на гибких магнитных дисках (НГМД);
14. Тест накопителей на жёстких магнитных дисках (НЖМД);
15. Самодиагностика функциональных подсистем BIOS;
16. Передача управления загрузчику.

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


Если всё прошло успешно, BIOS начинает процесс поиска загрузчика ОС. Для этого он начинает просматривать все подключенные к материнской плате жёсткие диски. Данные на физических дисках адресуются в единицах называемых сектор, обычно он 512 байт, однако современный стандарт 4096 байт. Установщик Windows в самый первый сектор на диске записывает специальный программный код и данные о разделах. Этот сектор называется Master Boot Record. Диск разбивается на разделы (partitions), отформатированный своей файловой системой. Максимум 4 раздела, каждый из который может быть расширенным (extended partition), такой можно рекурсивно делить на 4 раздела и теоретически их число не ограничено. Как только BIOS находит Master Boot Record он считывает оттуда код и передаёт ему управление. Этот код поочередно просматривает данные о разделах и находит тот который помечен как активный, в нём находится код загрузчика Windows (Это не раздел с C:\Windows\System32!), этот раздел называется system partition. Как правило он занимает 100Мб и скрыт от пользователя. В первом секторе этого раздела хранится загрузочный код, которому передаётся управление. Это volume boot sector, код в нём ищет файл Bootmgr, с которого и начинается процесс загрузки Windows. Файл Bootmgr создан через соединёние в один файлов Startup.com и Bootmgr.exe.

Процессор начинает свою работу в режиме который называется Реальный. Это режим совместимости, в нём CPU работает так же как и старые 16-bit процессоры, не имевшие поддержки виртуальной памяти и работавшие напрямую с физической памятью через 20-bit шину адресов, позволявшую адресовать 1Мб памяти. Простые MS-DOS программы выполнялись в этом режиме и имели расширение .COM. Первое что делает Startup.com (Bootmgr) переключает процессор в режим Защищённый, где под защитой понимается защита процессов друг от друга. В этом режиме поддерживается виртуальная память и 32х битные адреса, которыми можно адресовать 4Гб оперативной памяти. Следующим этапом Bootmgr заполняет таблицу виртуальных адресов на первые 16Мб RAM и включает трансляцию с виртуальных адресов в физические. В этом режиме и работает Windows. Поскольку на этом этапе подсистемы ОС ещё не созданы, Bootmgr имеет свою простую и неполную реализацию файловой системы NTFS, благодаря которой он находит BCD файл (Boot Configuration Data), в котором хранятся настройки параметров загрузки ОС. Вы можете редактировать его через утилиту BcdEdit.exe. В этих настройках BCD может быть указано, что Windows была в состоянии гибернации, и тогда Bootmgr запустит программу WinResume.exe, которая считывает состояние из файла Hyberfil.sys в память и перезапускает драйвера. Если BCD говорит, что есть несколько ОС, то Bootmgr выведет на экран их список и попросит пользователя выбрать. Если ОС одна, то Bootmgr запускает WinLoad.exe, этот процесс и выполняет основную работу по инициализации Windows:

1. Выбирает соотвествующую версию ядра Windows. Можете думать о нём как о Windows10.exe, хотя на самом деле он называется NtOsKrnl.exe. Какие есть версии? Согласно википедии:
   
   • ntoskrnl.exe однопроцессорное ядро Windows. без поддержки режима PAE
   • ntkrnlmp.exe (англ. NT Kernel, Multi-Processor version) многопроцессорное ядро Windows. без поддержки режима PAE
   • ntkrnlpa.exe однопроцессорное ядро Windows с поддержкой режима PAE.
   • ntkrpamp.exe многопроцессорное ядро Windows с поддержкой режима PAE.
   
   
2. Загружает HAL.dll (Hardware Abstraction Layer), который абстрагирует особенности материнки и CPU.
3. Загружает файл шрифтов vgaoem.fon
4. Загружает файлы в которых содержится инфомрация о представлениях даты времени, форматов чисел и пр. Эта функциональность называется National Language System.
5. Загружает в память реестр SYSTEM, в нём содержится информация о драйверах которые надо загрузить. Информация о всех драйверах находится в HKLM\SYSTEM\CurrentControlSet\Services\. Драйвера которые надо загрузить имеют ключ start = SERVICE_BOOT_START (0). Об устройстве реестра мы поговорим в другой статье.
6. Загружает драйвер файловой системы для раздела на котором располагаются файлы драйверов.
7. Загружает драйвера в память, но пока не инициализирует их из-за круговых зависимостей.
8. Подготавливает регистры CPU для выполнения ядра Windows выбранного на первом шаге NtOsKrnl.exe.

Во время загрузки драйверов WinLoad проверяет их цифровые подписи и если они не совпадают, то будет синий (BSOD) или зелёный (GSOD, для insider preview сборок) экран смерти.

Запуск на UEFI

Пример экрана загрузки UEFI

BIOS существует больше 30 лет и в попытках исправить его недостатки компания Intel в 1998 году создала стандарт Intel Boot Initiative, позже переименованный в EFI и в 2005 году пожертвованный организации EFI Forum. Недостатки BIOS:
Работает только в 16-битном режиме
Может адресовать только 1Mb оперативной памяти
Часто имеет проблемы совместимости
MBR ограничен только четырьмя главными разделами диска
Диск с ОС не может быть больше чем 2.2Tb.
Имеет очень ограниченные возможности для валидации загрузчика ОС.
На смену BIOS пришёл UEFI, по сути это миниатюрная ОС которая может работать и в 32-bit и в 64-bit. Для совместимости есть опция Compatibility Support Module, которая включается в настройках и эмулирует работу BIOS.


В UEFI загрузка происходит в родной для процессора битности 32 или 64, есть доступ ко всей памяти, поддерживается виртуальная память, включен Secure Boot и есть возможность запустить antimalware до начала загрузки ОС. Порядок загрузки ОС в UEFI:

1. Инициализация и запуск Firmware, запуск чип-сета.
2. POST тест, аналогично BIOS
3. Загрузка EFI-драйверов и поиск диска подпадающего под требования EFI для загрузочного диска
4. Поиск папки с именем EFI. Спецификация UEFI требует чтобы был раздел для EFI System Partition, отформатированный под файловую систему FAT, размером 100Мб 1Гб или не более 1% от размера диска. Каждая установленная Windows имеет свою директорию на этом разделе EFI\Microsoft.
   
5. Читает из настроек UEFI сохранённых в NVRAM (энергонезависимая память) путь к файлу загрузчика.
6. Находит и запускает EFI/Microsoft/Boot/BootMgrFw.efi.
7. BootMgrFw.efi находит раздел реестра BCD, который хранится в отдельном файле с именем BCD. Из него он находит WinLoad.efi, который расположен в C:\Windows\System32\winload.efi.

Чтобы посмотреть содержимое раздела EFI System Partition откройте консоль с правами админа (WinKey+X => Windows PowerShell (Admin)) и выполните команды mountvol Z: /s, Z:, dir. CD меняет директорию.
Главное отличие компонентов BootMgr и WinLoad для UEFI от своих копий для BIOS тем что они используют EFI API, вместо прерываний BIOS и форматы загрузочных разделов MBR BIOS и EFI System Partition сильно отличаются.

Инициализация ядра

Напоминаю, что мы рассматриваем загрузку ПК в контексте работы клавиатуры, поэтому не стоит заострять внимание на всех этапах. Надо понять где в этом процессе находится клавиатура, важные для понимания этапы выделены.
На предыдущем этапе был запущен компонент WinLoad.exe/WinLoad.efi, который запускает NtOsKrnl.exe указав ему параметры загрузки в глобальной переменной nt!KeLoaderBlock (память режима ядра доступна всем процессам), которые WinLoad собрал во время своей работы. Они включают:

1. Пути к System (загрузчик Windows) и Boot (C:\Windows\System32) директориям.
2. Указатель на таблицы виртуальной памяти которые создал WinLoad
3. Дерево с описанием подключенного hardware, оно используется для создания HKLM\HARDWARE ветки реестра.
4. Копия загруженного реестра HKLM\System
5. Указатель на список загруженных (но не инициализированных) драйверов участвующих в старте Windows.
6. Прочая информация необходимая для загрузки.

Инициализация ядра Windows происходит в два этапа. До этого происходит инициализация Hardware Abstraction Layer, который в числе всего прочего настраивает контроллеры прерывания для каждого CPU.
На этой же стадии загружаются в память строки с сообщениями для BSOD, потому как в момент падения они могут быть недоступны или повреждены.

• Первая фаза инициализации ядра:
  
  1. Слой Executive инициализирует свои объекты состояний глобальные объекты, списки, блокировки. Производится проверка Windows SKU (Stock Keeping Unit), примеры Windows 10 SKU Home, Pro, Mobile, Enterprise, Education.
  2. Если включен Driver Verifier, то он инициализируется.
  3. Менеджер памяти создаёт структуры данных, необходимые для работы внутренних API для работы с памятью (memory services), резервирует память для внутреннего пользования ядром.
  4. Если подключен отладчик ядра (kernel debugger) ему отправляется уведомление загрузить символы для драйверов загружаемых во время старта системы.
  5. Инициализируется информация о версии билда Windows.
  6. Старт Object Manager позволяет регистрировать именованные объекты к которым могут получать доступ по имени другие компоненты. Яркий пример мьютекс по которому приложение позволяет запустить единственный экземпляр. Здесь же создаётся храниться handle table, по которой устанавливается соответствие к примеру между HWND и объектом описывающим окно.
  7. Старт Security Reference Monitor подготавливает всё необходимое для создания первого аккаунта.
  8. Process Manager подготавливает все списки и глобальные объекты для создания процессов и потоков. Создаются процесс Idle и System (в нём исполняется Windows10.exe он же NtOsKrnl.exe), они пока не исполняются, потому как прерывания выключены.
  9. Инициализация User-Mode Debugging Framework.
  10. Первая фаза инициализации Plug and Play Manager. PnP это стандарт который реализовывается на уровне производителей периферии, материнских плат и ОС. Он позволяет получать расширенную информацию о подключенных устройствах и подключать их без перезагрузки ПК.
  
  
• Вторая фаза инициализации ядра. Она содержит 51 шаг, поэтому я пропущу многие из них:
  
  1. По завершению первой фазы главный поток процесса System (NtOsKrnl.exe) уже начал исполнение. В нём производится вторая фаза инициализации. Поток получает самый высокий приоритет 31.
  2. HAL настраивает таблицу прерываний и включает прерывания.
  3. Показывается Windows Startup Screen, которая по умолчанию представляет из себя чёрный экран с progress bar.
  4. Executive слой инициализирует инфраструктуру для таких объектов синхронизации как Semaphore, Mutex, Event, Timer.
  5. Объекты для User-Mode Debugger проинициализированы.
  6. Создана symbolic link \SystemRoot.
  7. NtDll.dll отображена в память. Она отображается во все процессы и содержит Windows APIs.
  8. Инициализирован драйвер файловой системы.
  9. Подсистема межпроцессного общения между компонентами Windows ALPC проинициализирована. Можете думать о ней как о named pipes или Windows Communication Foundation для межпроцессного общения.
  10. Начинается инициализация I/O Manager, который создаёт необходимые структуры данных для инициализации и хранения драйверов подключенной к компьютеру периферии. Этот процесс очень сложный.
      Здесь же инициализируются компоненты Windows Management Instrumentation и Event Tracing for Windows (на него полагается Windows Performance Analyzer). После этого шага все драйвера проинициализированы.
  11. Запускается процесс SMSS.exe (Session Manager Sub System). Он отвечает за создание режима пользователя, в котором будет создана визуальная часть Windows.
  
  

Запуск подсистем SMSS, CSRSS, WinInit

SMSS.exe отличается от пользовательских процессов, это нативный процесс и это даёт ему дополнительные полномочия. SMSS.exe работает с ядром в обход Windows API, он использует то что называется Native API. Windows API обёртка вокруг Native API. SMSS.exe первым делом запускает подсистему Windows (CSRSS.exe Client Server Runtime Sub System) и заканчивает инициализацию реестра.

Процесс и потоки SMSS.exe помечены как критические, это значит что если они неожиданно завершаться, к примеру из-за ошибки, это приведёт к падению системы. Для общения с подсистемами, к примеру вызову API создающему новую сессию, SMSS создаёт ALPC-порт с именем SmApiPort. Загружаются из реестра переменные среды окружения, запускаются программы такие как Check Disk (autochk.exe, эти программы записаны в реестре HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\BootExecute). SMSS.exe запускается для каждой пользовательской сессии. Глобальные переменные (очередь сообщений например) у каждой сессии своя за счёт механизма виртуальной памяти. В Windows есть контексты потока, процесса и сессии. Каждый SMSS.exe запускает свой экземпляр подсистемы, на данный момент это только CSRSS.exe (Windows), в прошлом поддерживались операционные системы OS/2 (os2ss.exe) и POSIX (psxss.exe), но эта идея была неудачной. Самый первый SMSS.exe засыпает в ожидании процесса WinInit.exe. Остальные экземпляры вместо этого создают процесс WinLogon который показывает UI для входа.

WinInit.exe инициализирует подсистемы для создания графической оболочки Windows Station и десктопы, это не тот рабочий стол который вы видите, это иная концепция Windows. Далее он запускает процессы:

1. Services.exe Services Control Manager (SCM) запускает сервисы и драйвера помеченные как AutoStart. Сервисы запускаются в процессах svchost.exe. Есть утилита tlist.exe, которая запущенная с параметром tlist.exe -s напечатает в консоли имена сервисов в каждом из svchost.exe.
2. LSASS.exe Local System Authority.
3. LSM.exe Local Session Manager.

WinLogon.exe загружает провайдеры аутентификации (credential providers), которые могут быть password, Smartcard, PIN, Hello Face. Он порождает процесс LogonUI.exe который и показывает пользователю интерфейс для аутентификации, а после валидирует введённые данные (логин и пароль, PIN).

Если всё прошло успешно, то WinLogon запускает процесс указанный в ключе реестра HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WinLogon\Userinit. По умолчанию это процесс UserInit.exe, который:

1. Запускает скрипты указанные в реестрах:
   • HKCU\Software\Policies\Microsoft\Windows\System\Scripts
   • HKLM\SOFTWARE\Policies\Microsoft\Windows\System\Scripts
2. Если групповая политика безопасности определяет User Profile Quota, запускает %SystemRoot%\System32\Proquota.exe
3. Запускает оболочку Windows, по умолчанию это Explorer.exe. Этот параметр конфигурируется через реестр:
   • HKCU\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell
   • HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell

WinLogon уведомляет Network Provider о залогинившемся пользователе, на что тот восстанавливает и подключает системные диски и принтеры сохранённые в реестре. Network Provider представляет из себя файл mpr.dll из системной папки, который хостится в процессе svchost.exe, т.е. сервис Windows.

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

Где здесь клавиатура?

Во время запуска ядро Windows считывает из реестра информацию о контроллере системной шины, как правило это шина PCI (реже MSI), к ней подключены контроллеры портов ввода-вывода, в том числе и USB, PS/2. Информация о нём записывается во время установки Windows. Система загружает для него драйвер и рекурсивно обходит все порты так же загружая для каждого из них свой драйвер. Драйвера могут комбинироваться в узлы (driver node), к примеру драйвер клавиатуры, будет соединён с драйвером порта PS2. А вот порт USB сложнее сначала драйвер порта, потом драйвер для работы с протоколом HID и только потом клавиатура.

Каждый порт контроллируется своим чипом, который мониторит подключение, принимает/отправляет сигналы между CPU и устройством. Если чип-сет Южный мост не встроен в CPU, как это часто делают в ноутбуках, а существует отдельным чипом на материнке, то правильней говорить: сигнал между Южным мостом и контроллером порта. Чип контроллирующий порт имеет выделенную линию с контроллером прерываний (PIC или APIC), по которой он может попросить обратить на себя внимание CPU, к примеру считать данные от клавиатуры (порт PS/2, с USB другая история). Поскольку ОС загрузила для порта драйвер, она может отдавать ему команды, читать и отправлять данные. В нашем примере был загружен драйвер из C:\Windows\System32\i8042prt.sys. Давайте вспомним предыдущую статью. В старых компьютерах с PIC на чипе Intel 8259 было 15 линий прерываний, где клавиатура была подключена к ножке IRQ1, таймер IRQ0, а мышка к IRQ12, который на самом деле был пятой ножкой второго чипа 8259, который мультиплексировал свои прерывания через ножку IRQ2 первого контроллера. В современных PIC могут быть 255 контактов для сигналов прерываний. Во время загрузки ОС программирует APIC/PIC возвращать определённое число когда скажем пришло прерывание от порта клавиатуры или USB и по этому номеру CPU находит в таблице векторов прерываний функцию которую надо выполнить. Номер прерываний определяют HAL и PlugnPlay Manager. Контроллер прерываний ищет сигнал на своих ножках в определённом порядке, к примеру в бесконечном цикле проверяет напряжение на ножках от 1 до MAX_PIN. Этот порядок определяет приоритет, к примеру клавиатура будет замечена раньше мышки, а таймер раньше клавиатуры. Чтобы не зависеть от особенностей работы контроллеров прерываний Windows абстрагирует концепцию IRQ (Interrupt Request) в IRQL (Interrupt Request Level). Будь у контроллера прерываний хоть 15 хоть 255 линий они все будут отображены на 32 IRQL для x86 и 15 IRQL для x64 и IA64. Что означают приоритеты IRQL:

1. High когда происходит краш системы, обычно это вызов функции KeBugCheckEx.
2. Power Fail не используется. Изначально был придуман для Windows NT.
3. Interprocessor Interrupt нужен отправить запрос другому CPU на мультипроцессорной системе выполнить действие, например обновить TLB cache, system shutdown, system crash (BSOD).
4. Clock нужен чтобы обновлять системные часы, а так же вести статистику сколько времени потоки проводят в режиме пользователя и ядра.
5. Profile используется для real-time clock (local APIC-timer) когда механизм kernel-profiling включен.
6. Device 1 Device N прерывания от устройств I/O. Во время прерывания данные от клавиатуры, мыши и других устройств считываются в отдельные буфера и сохраняются в объектах типа DPC (Deferred Procedure Call), чтобы обработать их позже и дать возможность устройствам переслать данные. После приоритет снижается до Dispatch DPC
7. Dispatch DPC как только данные от устройств получены можно начинать их обрабатывать.
8. APC Asynchronous Procedure Call. Через этот механизм вы можете исполнить код когда поток будет спать вызвав WaitForSingleObject, Sleep и другие.
9. Passive/Low здесь исполняются все приложения в User Mode.

Если вы всегда программировали в режиме пользователя, то никогда не слышали про IRQL, потому что все пользовательские программы выполняеются с приоритетом Passive/Low (0). Как только происходит событие с большим уровнем приоритета (событие от клавиатуры, таймер планировщика потоков), процессор сохраняет состояние прерванного потока, которое представляет из себя значения регистров CPU, и вызывает диспетчер прерываний (interrupt dispatcher, просто функция), который повышает приоритет IRQL через API KeRaiseIrql в HAL и вызывает непосредственно сам код обработчика (interrupts service routine). После этого IRQL CPU понижается до прежнего уровня через функцию KeLowerIrql и прерванный поток начинает обработку с того же места где его прервали. На этом механизме основан планировщик потоков. Он устанавливает таймер, который с определённым интервалом (квант времени) генерирует прерывание с приоритетом DPC/Dispatch (2) и в своей interrupts service routine по определённому алгоритму назначает новый поток на исполнение.

Механизм IRQL реализовывается на уровне софта в Hardware Abstraction Layer (HAL.dll), а не железа. В Windows системах есть драйвер шины (bus driver), который определяет наличие устройств подключенных к шинам PCI, USB и др. и номера прерываний которые могут быть назначены каждому устройству. Драйвер шины сообщает эту информацию Plug and play manager, который уже решает какие номера прерываний назначить каждому устройству. Далее арбитр прерываний внутри PnP Mgr (PnP interrupt arbiter) устанавливает связи между IRQ и IRQL.

Когда приходит прерывание от клавиатуры, любой исполняемый в данный момент поток (это может быть ваша программа) назначается на его обработку. Interrupt dispatcher повышает приоритет IRQL CPU до одного из уровней Device1-DeviceN. После этого менеджер виртуальной памяти не сможет найти страницу если она не загружена в RAM (не сможет обработать Page Fault), планировщик потоков не сможет прервать выполнение, потому что они все работают с меньшим уровнем IRQL. Главная задача драйвера клавиатуры в этот момент считать полученные данные и сохранить их для дальнейшей обработки. Данные записываются в объект типа _DPC (Deferred Procedure Call), который сохраняется в список DPC потока (что-то вроде std::list<DPC>, в ядре ОС вместо массивов используются связанные списки). Как только прерывания от всех внешних устройств обработаны, IRQL потока понижается до уровня DPC в котором и производится обработка отложенных процедур (DPC). В коде обработчика DPC для клавиатуры вызывается функция из драйвера клавиатуры Kbdclass.sys:

VOID KeyboardClassServiceCallback(  _In_    PDEVICE_OBJECT       DeviceObject,  _In_    PKEYBOARD_INPUT_DATA InputDataStart,  _In_    PKEYBOARD_INPUT_DATA InputDataEnd,  _Inout_ PULONG               InputDataConsumed);

Так вот, драйвер клавиатуры (kbdclass.sys) получает данные от порта (USB, PS2) через прерывание и записывает их через WriteFile, компонент внутри ядра Windows просыпается, считывает их используя API ReadFile и добавляет в очередь сообщений с клавиатуры. API для работы с файлом могут использоваться для чтения данных с драйверов. С этого момента начинается обработка данных стеком ввода Windows, об этом в следующей статье.

Если у вас есть ПК с PS2 портом и вы умеете пользоваться WinDbg в режиме ядра, то можете легко найти обработчик прерываний клавиатуры напечатав команду !idt, которая выведет на экран всю таблицу векторов прерываний. Прерывание вклинивается в ход выполнения программы, слово вектор здесь подразумевает направление, направление исполнения программы. WinDbg был сделан специально для отладки Windows, самая последняя версия называется WinDbgX. Он имеет текстовый интерфейс, который отпугивает людей привыкших к Visual Studio, однако предоставляет гораздо больше возможностей, в частности исполнение скриптов. Прерывание фиолетового порта PS2 выделено красным. Функция которая его обрабатывает называется I8042KeyboardInterruptService, которая находится в файле i8042prt.sys.

BOOLEANI8042KeyboardInterruptService(  IN  PKINTERRUPT Interrupt,  IN  PVOID Context  );Routine Description:    This is the interrupt service routine for the keyboard device when    scan code set 1 is in use.Arguments:    Interrupt - A pointer to the interrupt object for this interrupt.    Context - A pointer to the device object.Return Value:    Returns TRUE if the interrupt was expected (and therefore processed);    otherwise, FALSE is returned.

Сейчас возникает вопрос, откуда у обработчика прерываний аргумент? Кто его передаёт? Ведь CPU ничего не знает о нём. Если поставите в неё breakpoint, то удивитесь ещё больше увидев несколько функций выше по стеку:

0: kd> kC
# Call Site
00 i8042prt!I8042KeyboardInterruptService
01 nt!KiCallInterruptServiceRoutine
02 nt!KiInterruptSubDispatch
03 nt!KiInterruptDispatch
04 nt!KiIdleLoop

Объяснение здесь простое это не та функция которая сохранена в регистре IDT процессора. То что вы видите на картинке выше на самом деле объекты типа _KINTERRUPT. В таблице прерываний сохранён специальный ассемблерный код (nt!KiIdleLoop), который знает как найти объект описывающий прерывание в памяти. Что же интересного есть в нём?

1. Указатель на объект представляющий драйвер в памяти.
2. Указатель на функцию i8042prt!I8042KeyboardInterruptService, которая и вызывает код считывающий данные из порта PS2 через ассемблерную команду IN AL, 0x60 сохранить значение из порта номер 0x60 в регистре AL.
3. Функция dispatcher ей передаётся указатель функцию из пункта 2 и она вызывает её.
4. Состояние регистров CPU. Перед вызовом прерывания состояние CPU будет сохранено сюда, и отсюда же будет восстановлено.
5. Приоритет прерывания. Не тот который определяет контроллер прерываний, а тот который Windows считает нужным. Это IRQL (Interrupt Request Level) абстракция над IRQ.

Как только обработчик прерываний клавиатуры будет вызван, он уведомит драйвер клавиатуры о полученных данных, после чего будет уведомлено ядро ОС, которое обработав данные отправит их дальше по стеку ввода, где они могут быть доставлены приложению, которое на них отреагирует, или перед этим в обработчик языков (азиатские иероглифы, автокоррекция, автозаполнение).
Ядро ОС напрямую не взаимодействует с драйвером клавиатуры, для этих целей используется PlugnPlay Manager. Этот компонент предоставляет API IoRegisterPlugPlayNotification, который вызовет предоставленную callback-функцию когда устройство будет добавлено или удалено.

Пару слов о USB

Ознакомление с работой порта USB потребовало бы отдельной статьи описывающей его работу и плюс описание обработки данных HID на Windows. Это очень сильно усложнило бы материал, к тому же уже есть хорошие статьи по теме, поэтому PS2 идеальный пример из-за своей простоты.

USB создавался как универсальный порт для всех устройств, будь то клавиатура, фотоаппарат, сканнер, игровой руль с педалями, принтер и пр. Вдобавок он поддерживает вложенность портов USB материнки => монитор с USB => клавиатура с USB к которой подключена мышка, флешка и USB-hub к которому подключен жёсткий диск. Взглянув на контакты USB 2.0 вы увидите что они не заточены под передачу каких-то определённых данных, как у PS2. Их всего четыре витая пара для передачи битов данных, плюс и минус питания.


Провода кабеля USB 2.0

USB 3.0 быстрее за счёт дополнительных пяти контактов. Как видите там нету линии CLOCK для синхронизации, поэтому логика передачи данных сложнее. Слева USB 2.0 и справа USB 3.0 для сравнения.
Все данные передаются через протокол HID (Human Interface Device), который описывает форматы, порядок взаимодействия и передачи данных и всё остальное. Стандарт USB 2.0 занимает 650 страниц, документ HID Class Specification, описывающий работу устройств (мыши, клавиатуры и пр) 97 страниц, их рекомендуется изучить если вы работаете с USB.

Первым делом подключенное устройство должно рассказать о себе, для этого оно отправляет несколько структур данных, в которых указывается ID устройства и ID производителя по которым PlugnPlay manager может найти в реестре информацию, загрузить и соединить драйвера. USB устройства пассивны, т.е. хост должен сам с определённым интервалом проверять наличие данных. Частота опроса и размер пакета данных задаются в одном из дескрипторов устройства USB. Максимальный размер пакета 64 байта, что для информации о нажатых клавишах более чем достаточно.

В Windows есть встроенная поддержка HID, она не такая простая как связь драйвера порта PS2 с драйвером клавиатуры, потому что драйвер HID должен уметь обрабатывать все поддерживаемые протоколом сценарии. Вне зависимости от провайдера данных порты PS2, USB или Remote Desktop или виртуальная машина на самом верху driver node будет находится Kbdclass, от которого ядро ОС и будет получать информацию. Уведомления о подсоединении клавиатуры будет обрабатываться через PlugnPlay Manager, так что для ядра Windows не имеет значение какой порт или источник данных устройства используется используется.

Приветствую!

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

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

Можно на это возразить, что кому интересна академическая разработка, тому надо книги читать, а не HOWTO-посты в интернете. С другой стороны, в книгах вроде трудов Э.Таненбаума тоже есть недостатки, которые и приводят к тому, что поток постов, упомянутых выше, не иссякает. Книга Таненбаума (про MINIX) все-таки довольно высокого уровня и многие вопросы, которые возникают на практике, там вообще не рассматриваются. И есть еще один момент. Развитие ОС общего назначения и ОСРВ исторически шло в противоположных направлениях: в UNIX-подобных ОС вначале появились однопоточные процессы, и только спустя время процессы стали многопоточными; в области ОСРВ было наоборот, вначале появились однопроцессные многопоточные системы, а уже потом процессов могло стать более одного. Есть мнение, что для изучения лучше как раз второй случай, потому что начинать можно с более простого и усложнять постепенно, а прийти в итоге к одному и тому же. Но я отвлекся.

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

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

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

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

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

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

В качестве иллюстрации описываемых принципов используется FX-RTOS, как один из возможных подходов в том числе и к этой проблеме. Разумеется, для того, чтобы можно было описывать одни части ядра не касаясь других частей, оно должно быть написано таким образом, чтобы позволять это. Хотя тут я ставлю телегу немного впереди лошади, потому что сначала все-таки появилась сама ОС, а потом уже стало понятно, что ее архитектура хорошо подходит для того, чтобы на ее примере изучать предмет, так как можно наращивать функциональность очень мелкими шагами и вводить все понятия постепенно.
Упомянутые выше исходники могут использоваться для иллюстрации концепций вплоть до 6 главы включительно, дальше уже можно плавно переходить к MINIX :-)

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

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

P.S. Если тема окажется интересной, позже напишу про саму FX-RTOS.

Об операционной системе Fuchsia от Google впервые стало известно четыре года назад. Тогда писали, что корпорация разрабатывает проект на основе микроядра Zircon. Это небольшая ОС, предназначенная для большого количества платформ от смартфонов, планшетов и персональных компьютеров до встраиваемых систем.

Проект относительно активно развивался несколько лет, причем пару лет подряд в сети публиковались предположения о том, что Google разрабатывает ее в качестве альтернативы Android. Все это время ОС продолжала развиваться. Например, в 2017 году сообщалось, что ОС получила новый пользовательский интерфейс, возможности командной строки и еще несколько возможностей. В 2018 году Google выложила новую версию своей ОС, которую уже можно было протестировать. Но потом все как-то затихло. И сейчас стало известно о новом варианте развития Fuchsia.

Речь идет о проекте dahliaOS, который собрал все лучшее от Fuchsia, добавил технологии из GNU/Linux и предлагает нечто новое. Проект пишется на основе языка Dart и распространяется под лицензией Apache 2.0. Разработчики готовят два варианта ОС для систем с UEFI (158 МБ) и виртуальных машин или устаревших морально систем.


Что касается последнего варианта, то он готовится на основе микроядра Zircon, о котором шла речь выше и ОС Fuchsia. Эти сборки уже доступны для таких платформ, как Raspberry Pi 4, msm8917 и небольшого количества других устройств.

При этом разработчики планируют использовать собственную пользовательскую оболочку Pangolin, которая написана на языке Dart с использованием фреймворка Flutter. Эта оболочка уже поддерживает мозаичный режим компоновки окон. Основа для этой оболочки части проекта Capybara и собственные разработки, включая собственную систему управления окнами, которая написана с нуля. Все это уже можно протестировать, правда, пока в виде web-версии, которая совместима лишь с Chrome.

Запускается эта система в системах с ядром Linux и микроядром Zircon. Для нового дистрибутива нужны приложения, которые разрабатываются и уже доступны. Пишутся они на Dart и Flutter. Сейчас уже есть файловый менеджер, конфигуратор, текстовый редактор, эмулятор терминала, приложение для управления виртуальными машинами и контейнерами, мультимедиа плеер и каталог приложений.


В окружении Pangolin можно запускать и сторонние программы, для чего система поддерживает изолированные контейнеры. Благодаря им в среде ОС можно запустить любое приложение, которое не связано с ней. Для того, чтобы в dahliaOS можно было запускать на системах с UEFI, разработчики предусмотрели приложение system-recovery, которое дает возможность автоматически загружать свежий образ системы в случае серьезных проблем. Загрузиться можно при помощи этого образа.

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

Единственная проблема хромбуков то, что в качестве ОС используется Chrome OS с браузером Chrome или Chromium. Это ПО нравится хотя и многим, но не всем. Большое количество пользователей принимает Chrome OS вынужденно, не имея альтернативы. Но теперь, кажется, она появилась. Речь идет о дистрибутиве Linux, который получил название Ubuntu Web Remix. Его начали разрабатывать в начале лета, а сейчас он доступен для загрузки.

Основа дистрибутива Ubuntu. Но разработчик постарался следовать минимализму Chrome OS, упростив интерфейс оригинальной операционной системы. Вместо Google Chrome здесь используется браузер Firefox, несколько веб-приложений из /e/, плюс Anbox, инструмент, который дает возможность запускать Android-приложения на Linux.

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


Дистрибутив дает возможность установить практически любое приложение для Ubuntu при помощи apt-get, но вот Ubuntu Software Center в этой ОС нет. Вместо этого используется линк на Open Web Store, размещенный в таскабре. При клике по ярлыку пользователь попадает на сат, где можно найти набор приложений на все случаи жизни. После загрузки и установки они отображаются в списке приложений ОС.

Для работы каждого из эти веб-приложений используется браузер Firefox. Каждое новое запущенное приложение открывается в новой вкладке.

Сейчас в базе Open Web Store есть SoundCloud, YouTube, Facebook, Twitter и Mastadon. Но сторонние разработчики могут создавать собственные веб-приложения, предлагая их автору проекта для размещения. При желании можно разрабатывать веб-приложения для самого себя автор предоставил необходимый инструмент.


Может ли Ubuntu Web Remix на текущем этапе заменить собой Chrome OS? Пока что нет, проекту нужно еще поразвиваться некоторое время. Тем не менее, базовые функции эта ОС выполняет, так что использовать дистрибутив для решения ряда обычных задач вполне можно.

Сложно сказать, когда Ubuntu Web Remix станет хотя бы приблизительно такой же функциональной операционной системой, как Chrome OS ведь у разработчика нет тех же ресурсов, что есть у корпорации Google. Да и приобрести убунтубук с предустановленной Ubuntu Web Remix тоже нельзя по крайней мере, пока.


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

Стоит отметить, что разработчик, создавший этот дистрибутив, развивает и проекты Ubuntu Unity Remix с Ubuntu Education. Что касается первого упомянутого проекта, то это модифицированный дистрибутив Ubuntu 20.04, он базируется на оболочке Unity версии 7 и оконным менеджером Compiz. Второй проект дистрибутив, предназначенный для использования в школах, вузах и других учебных заведениях.

Несмотря на то, что у корпорации Google есть две популярные операционные системы Android и Chrome OS, она взялась за разработку третьей Fuchsia OS. Впервые о ней стало известно четыре года назад: тогда сообщалось, что операционная система основана на микроядре Zircon.

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

Это реально отличная возможность поучаствовать, вот только есть одна проблема: до сих пор неизвестно, для чего разрабатывается эта операционная система. Одни догадки, так как сам Google пока не афиширует цели этой ОС. Единственное, что раскрыла корпорация, это то, что проект долгосрочный, а операционная система общего назначения и будет распространяться по модели Open Source.

Корпорация сделала дорожную карту Fuchsia OS доступной для всех, так что любой пользователь сможет лучше понимать статус проекта.

Возможно, Google планирует стать полностью независимой компанией, поскольку Fuchsia не базируется на ядре Linux. А значит, компания может делать что угодно с собственной операционной системой. Так, Google сможет адаптировать Fuchsia под определенные устройства, чем бы они ни были, на все 100%.

Что касается процесса разработки, то да, к нему может присоединиться любой. Но код будет целиком и полностью принадлежать компании, что делает ее лицензию похожей на BSD. Поэтому Fuchsia на 100% инициатива Google и ничья другая, хоть проект теперь и открыт миру.

Вполне может быть, что кто-то из разработчиков сможет понять, для чего компания разрабатывает ОС, покопавшись в коде. Сейчас ее планируют сделать доступной для таких устройств, как Acer Switch Alpha 12, Intel NUC и Google Pixelbook.


Кстати, раньше мы писали, что для Fuchsia есть еще один вариант развития это проект dahliaOS. Он пишется на основе языка Dart и распространяется под лицензией Apache 2.0. Разработчики готовят два варианта ОС для систем с UEFI (158 МБ) и виртуальных машин или морально устаревших систем.


Что касается второго варианта, то он готовится на основе микроядра Zircon, о котором шла речь выше, и ОС Fuchsia. Эти сборки уже доступны для таких платформ, как Raspberry Pi 4, msm8917 и небольшого количества других устройств.

При этом разработчики планируют использовать собственную пользовательскую оболочку Pangolin, которая написана на языке Dart с использованием фреймворка Flutter. Эта оболочка уже поддерживает мозаичный режим компоновки окон. Основа для этой оболочки части проекта Capybara и собственные разработки, включая систему управления окнами, написанную с нуля. Все это уже можно протестировать, правда, пока в виде web-версии, которая совместима лишь с Chrome.

Импортозамещение в Китае активно реализуется. На днях была представлена мобильная операционная система JingOS, которая предназначена для планшетов. В ближайшее время разработчики планируют создать и версию для смартфонов, так что эта ОС прямой конкурент (пока лишь для Китая) Android и iOS.

Сейчас ОС работает на планшетных ПК с x86-процессорами. Вскоре будет выпущена ARM-версия, для смартфонов и планшетов с чипами на этой архитектуре. Система уже вышла из стадии прототипа, с ней можно полноценно работать. Основа ее Ubuntu 20.04, которая вышла весной этого года. Сейчас она доступна в виде бета-версии, китайцы выложили систему в свободном доступе.

Окружением для модифицированной Ubuntu служит KDE Plasma Mobile 5.2. При разработке интерфейса создатели системы явно воспользовались примером iOS. Это выражается и в построении интерфейса, и в некоторых его элементах. Возможно, это временный шаг, на который разработчики пошли, чтобы привлечь внимание потенциальных пользователей.


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


Чтобы получить дистрибутив, нужно указать свой адрес электронной почты, на который разработчики пришлют письмо с со ссылкой на скачивание. Кроме того, есть возможность получить образ и через Telegram. Объем файла дистрибутива составляет 2,5 ГБ.

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


В марте выйдет новый апдейт с индексом 0.8. На этом этапе она будет лишена большинства проблем, которые есть сейчас. Работоспособность системы уже протестировали на таких платформах, как ПК Huawei MateBook 14, Chuwi Minibook и Eve V. Также она установилась и без проблем работает на Microsoft Surface Pro 6.

К сожалению, пока что исходный код системы недоступен его откроют после релиза финальной версии в июне этого года. Кстати, тогда же KDE, скорее всего, заменят на китайскую оболочку JDE или Jing Desktop Environment.


У китайцев, к слову, есть конкуренты система Ubuntu Touch, которая продолжает развиваться энтузиастами, после отказа от проекта компанией Canonical в 2017 году. Последняя стабильная версия системы 16.04 OTA. Но, к сожалению, Ubuntu Touch так и не стала популярной, хотя и разрабатывается с 2011 года.

Сегодня одни хорошие новости на Хабре. Так, марсолет совершил свой второй полет, а мы почти сразу получили шикарное видео этого события. Ну и к вечеру еще новость Canonical вот только что зарелизила Ubuntu 21.04 Hirsute Hippo с нативной интеграцией Microsoft Active Directory, дефолтным Wayland и SDK для Flutter. Кроме того, Canonical и Microsoft объявили об оптимизации производительности Microsoft SQL Server и совместной поддержке продукта.

Интеграция Native Active Directory и сертифицированный Microsoft SQL Server на Ubuntu приоритетные нововведения для корпоративных пользователей. Ну а для разработчиков Ubuntu 21.04 предоставляет Wayland и Flutter, заявил Марк Шаттлворт, СЕО Canonical. Давайте посмотрим, что там еще за сюрпризы нас ожидают.

А их, сюрпризов, немало:

• В новом дистрибутиве в качестве рабочего стола используется GNOME Shell 3.38, собранного с использованием GTK3. Собственно, так все и было, но теперь приложения GNOME синхронизированы с GNOME 40, поскольку разработчики решили, что переходить на GTK 4 пока еще рано.
• Как и говорилось выше, по умолчанию используется сеанс на базе протокола Wayland. В случае использования проприетарных драйверов Nvidia пользователю предлагается сеанс на основе X-сервера. А вот для прочих конфигураций этот сеанс переведен в разряд опций. За последние несколько месяцев устранен ряд ограничений сеанса GNOME на базе Wayland. После этого появилась возможность предоставления совместного доступа к рабочему столу посредством мультимедийного сервера Pipewire.
• Впервые на Wayland Ubuntu попытались перевести в 2017 году, но из-за ряда проблем пришлось вернуть графический стек на основе X.Org Server. К слову, Wayland поддерживается теперь и сборками для малинки, Так, добавлена поддержка GPIO (через libgpiod и liblgpio). Для плат Compute Module 4 реализована поддержка Wi-Fi и Bluetooth.
• Появились нескучные обои тема оформления Yaru и пиктограммы для типов файлов.

• Кроме всего прочего, разработчики добавили поддержку мультимедийного сервера Pipewire. Это дает возможность организовать запись содержимого экрана, улучшает поддержку звука в изолированных приложениях, а также открывает возможность профессиональной обработки звука и избавляет от фрагментации.
• Ядро Linux обновлено до версии 5.11. В нем, кроме поддержки анклавов в Intel SGX, появился новый механизм перехвата системных вызовов, виртуальная шина auxiliary, запрет сборки модулей без MODULE_LICENSE(), режим быстрой фильтрации системных вызовов в seccomp, прекращение сопровождения архитектуры ia64, перенос технологии WiMAX в ветку staging, возможность инкапсуляции SCTP в UDP.
• Пакетный фильтр nftables задействуется по умолчанию. Но для обеспечения обратной совместимости предусмотрен пакет iptables-nft, который предоставляет утилиты с тем же синтаксисом, что и у iptables, но с трансляцией полученных правил в nf_tables.
• Появилась поддержка аутентификации с использованием смарт-карт.
• Добавлена возможность изменения профиля энергопотребления, а на рабочем столе теперь можно перемещать ресурсы из приложений при помощи метода Drag&Drop.
• Инсталлятор поддерживает создание резервных ключей для восстановления доступа к зашифрованным разделам. Их можно использовать для расшифровки, если пароль утерян.
• Теперь подробнее про интеграцию с Active Directory. Кроме улучшения интеграции, разработчики добавили возможность аутентификации пользователей в Active Directory с поддержкой GPO (Group Policy Objects) сразу после установки Ubuntu. Таким образом системные администраторы получили возможность размещать настройки непосредственно в контроллере домена Active Directory для рабочих станций Ubuntu (включая настройки рабочего стола и набор пользовательских приложений). Для определения политик обеспечения безопасности клиентов можно использовать GPO, включая задание параметров доступа пользователей и правил оформления паролей.
• Внесены изменения в модель доступа к домашним каталогам пользователей в системе. Последние создаются с правами 750 (drwxr-x---), предоставляющими доступ к каталогу только владельцу и членам группы. Раньше у пользователей была возможность просматривать содержимое каталогов других пользователей.
• Поддержка режима UEFI SecureBoot улучшена для систем x86_64 (amd64) и AArch64 (arm64). В прослойке для организации верифицированной загрузки применяется механизм SBAT (UEFI Secure Boot Advanced Targeting). Он решает проблемы с отзывом сертификатов. Поддерживают этот механизм теперь пакеты grub2, shim и fwupd.

• Обновлен ряд системных компонентов и языков программирования, включая:

GCC 10.3.0,
binutils 2.36.1,
glibc 2.33,
Python 3.9.4,
Perl 5.32.1,.
LLVM 12,
Go 1.16,
Rust 1.50,
OpenJDK 16,
Ruby 2.7.2,
Rails 6.

• Также обновлены версии приложений и подсистем, таких как:

Mesa 21.0,
PulseAudio 14,
BlueZ 5.56,
NetworkManager 1.30,
Firefox 87,
LibreOffice 7.1.2,
Thunderbird 78.8.1,
Darktable 3.4.1,
Inkscape 1.0.2,
Scribus 1.5.6.1,
OBS 26.1.2,
KDEnlive 20.12.3,
Blender 2.83.5,
Krita 4.4.3,
GIMP 2.10.22.

• Дополнительно обновлены компоненты для серверных систем:

PostgreSQL 13.2,
Samba 4.13.3,
QEMU 5.2,
SSSD 2.40,
Net-SNMP 5.9,
DPDK 20.11.1,
Strongswan 5.9.1,
Open vSwitch 2.15,
Chrony 4.0,
OpenVPN 2.5.1,
Virt-manager 3.2.0,
Libvirt 7.0,
Rsyslog 8.2102.0,
Docker 20.10.2,
OpenStack Wallaby.

• Появились сборки для плат HiFive SiFive Unleashed и HiFive SiFive Unmatched на базе архитектуры RISC-V. О RISC-V платах мы писали здесь.
• Для iSCSI теперь применяется инструментарий targetcli-fb. Ранее использовался tgt.
• В состав Ubuntu Server включен пакет needrestart. Он запускается в конце каждой транзакции APT, выявляет изменения, требующие перезагрузки, и информирует об этом администратора.
• Ликвидирована поддержка lua-модуля для nginx, который не совместим с новыми версиями nginx. Разумеется, nginx поддерживается, но вместо отдельного модуля теперь есть специальная редакция Nginx с интегрированной поддержкой LuaJIT.
• В Kubuntu, Xubuntu, Ubuntu MATE, Ubuntu Studio, Lubuntu внесены изменения в рабочие столы и ПО.

• Плюс сообщество предложило два неофициальных варианта Ubuntu 21.04: Ubuntu Cinnamon Remix 21.04 с рабочим столом Cinnamon и Ubuntu Unity Remix 21.04 с рабочим столом Unity.

Загрузить Ubuntu 21.04 можно по этой ссылке.

На Хабре многие внимательно следят за судьбой молодой ОС Fuchsia OS от Google. Долгое время ее предназначение и позиционирование оставались достаточно туманными. Компания рассказывала о том, что ОС можно использовать на широком спектре разных устройств, но, где именно, оставалось лишь догадываться.

Похоже, что вскоре эту ОС можно будет потрогать. Как оказалось, в Сеть утекли спецификации нового умного устройства Google, обновленной модели Nest Hub. И ее программное обеспечение как раз эта загадочная операционная система. Вполне может быть, что она быстро станет чем-то большим, чем нишевой ОС, как это случалось с другими платформами.

Немного подробностей о Google Nest с цветочком

К слову, в том, что операционная система будет установлена именно на Nest Hub, нет ничего удивительного. Компания ранее тестировала ее на разных потребительных устройствах, включая Google Pixelbook, Nest Hub и Nest Hub Max.

На днях спецификации нового устройства (вернее, модифицированного) опубликованы Bluetooth Special Interest Group. Это не совсем утечка, а вполне официальный документ, но не от Google. Девайс не новый это устройство 2018 года с новой прошивкой. После ребрендинга его назвали Google Nest Hub, ранее оно называлось Google Home Hub.

Ранее в поле Software Version Number для девайса было указано, что его операционная система платформа Cast. Сейчас же красуется надпись Fuchsia 1.0.


Можно, конечно, попробовать установить Fuchsia и сейчас, ведь ее исходники находятся в свободном доступе. Но, к сожалению, сделать это сложно, если вообще возможно. Устройства защищены от загрузки неподписанного и не авторизованного вендором ПО. Конечно, умельцы смогут обойти этот момент, но, возможно, тратить время сейчас и не нужно, поскольку после выхода основного девайса с Fuchsia на борту все станет гораздо проще.

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

Fuchsia OS открытый проект

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

Исходный код ОС был впервые опубликован в августе 2016 года, в течение четырех лет разработчики вели разработку открыто, с прозрачным репо проекта.

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

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

Особенности Fuchsia

Основа ОС не Linux, а микроядро Zircon. Тем не менее, в ОС уже предоставляется уровень совместимости POSIX Lite, работающий поверх Fuchsia System ABI. Все это позволяет обеспечить запуск ряда Linux-программ, но при этом нужно перекомпилировать приложения или даже модифицировать исходные тексты. Одна из проблем POSIX Lite неполная реализация всех возможностей POSIX.

У Fuchsia есть собственный графический интерфейс, который написан на Dart с использованием фреймворка flutter.

Кроме того, проект развивает:

• фреймворк для построения интерфейсов пользователя Peridot;
• пакетный менеджер Fargo;
• стандартную библиотеку libc;
• систему рендеринга Escher;
• Vulkan-драйвер Magma;
• композитный менеджер Scenic;
• файловые системы MinFS, MemFS, ThinFS (FAT на языке Go) и Blobfs
• менеджер разделов FVM.

Для разработки приложений предоставляется поддержка языков C/C++, Dart, в системных компонентах также допускается использование Rust, в сетевом стеке Go, а в системе сборки языка Python.

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

Новая версия, несмотря на то, что она еще не вышла, считается релизом с максимальным количеством изменений за всю историю Linux. В коде релиза появилось свыше 1 млн новых строк. Скорее всего, оценить новинку можно будет в ближайшие пару недель Линус Торвальдс выпустит RC1, если не произойдет ничего экстраординарного.

А пока обсудим список изменений.

Так, новое ядро оптимизировано под работу с новейшими процессорами от Intel и AMD, рядом других чипов и модулей, архитектурой ARM. Добавлены сетевые компоненты, появились новые open source драйверы графики AMD Radeon. Кстати, стабильная версия этой ветки ожидается примерно к концу лета началу осени. Именно тогда должны появиться Ubuntu 20.10 и Fedora 33 с поддержкой нового ядра.

В новом ядре есть возможность конфигурировать флеш-массивы на базе MLC в качестве SLC. Развитие получил драйвер Microsoft exFAT, оптимизированы SMB3, EXT4 и Btrfs. Также добавлена поддержка DAX для прямого доступа к энергонезависимой памяти.


Источник

Кроме того, команда Linux добавила следующие нововведения:

• Поддержка шифрования с использованием Trusted Memory Zones на GPU AMD;
• Поддержка буферов обмена P2P/DMA между графическими ускорителями (в частности, для свежих AMD);
• Обновления драйверов AMD, NVIDIA и Intel (включая начальную поддержку Gen12), а также Habana Gaudi;
• Драйвер AMD Energy наконец-то откроет для доступа сенсоры Zen/Zen 2;
• Появится поддержка живой миграции с KVM для процессоров AMD;
• Драйвер CPUFreq получит поддержку boost;
• Появится поддержка PCIe NTB для Intel Ice Lake Xeon;
• Реализована начальная поддержка архитектуры POWER10;
• Уже ставшие традиционными патчи против side-channel уязвимостей для основных архитектур и их оптимизации.

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

Известно, что примерно 40% изменений в новом ядре связано с драйверами, 16% с обновлением кода для различных процессорных архитектур, 10% изменений связаны с сетевым стеком, 3% с файловыми системами.

Общее количество новшеств превысило 14 000, и они затронули примерно 20% файлов в репозитории. Размер патча 5.8-rc1 61 МБ.

А вы ждете новый релиз Linux? Пишите, что думаете об изменениях, в комментариях!

Корпорация Google опубликовала релиз мобильной ОС Android 11. Исходные тексты операционной системы размещены в Git-репозитории проекта (ветка android-11.0.0_r1).

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

Что нового в Android 11?

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



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

Наконец-то появилась встроенная функция записи экрана, которая поддерживает запись звука как от микрофона, так и с самого устройства.

Добавлена поддержка беспроводного подключения к Android Auto.



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

Настройки разрешения давно не используемых приложений сбрасываются.

Есть и меню управления умными устройствами. Активировать его можно по долгому нажатию кнопки питания. В этом же меню разместили раздел с картами Google Pay.



Разработчики изменили дизайн элементов управления медиаконтентом. Появилась возможность быстрого переключения воспроизведения между устройствами, включая колонки, умные часы, наушники и т.п.



ОС сначала обновится на смартфонах компаний Google, OnePlus, Xiaomi, Realme и Oppo. Остальные получат обновления в ближайшие месяцы.

Мы несколько раз писали о разработках компании Huawei. Попав под санкции США, она начала создавать собственные аппаратные и программные решения. В частности процессоры и ПО. Чаще всего среди этих разработок упоминается операционная система Harmony OS, которая, как многие считали, создавалась с нуля.

Разработка стартовала в 2019 году, и сейчас представлена уже вторая версия системы. При этом президент отдела разработки ПО Huawei заявил в свое время следующее: Harmony OS не является ни копией Android, ни копией iOS. Но так ли это? Как узнали в редакции Arstechnica, слова разработчиков очень сильно расходятся с реальностью.

Как удалось получить Harmony OS для теста?

Это, как оказалось, долгий и сложный процесс, который требует регистрации. И не просто указания никнейма, почты и т.п. Разработчики (не забываем, речь идет о Китае) просят полный список документов для идентификации личности. Главный в этом списке паспорт. Пришлось отсканировать и отправить все страницы.

Сравните это с Android, для скачивания которого нужно зайти на страничку с Android SDK и кликнуть по линку, после чего начинается загрузка. Чуть сложнее процесс у Apple, но и там ничего фатального.



Но паспортом дело не ограничивается. При создании аккаунта нужны еще и другие документы, включая кредитную карту. Да, именно требуется фотография лицевой стороны карты. Кроме того, необходимо указать полное имя, email, телефон. После ввода данных нужно ждать два рабочих дня. Затем, если повезет, аккаунт одобрят процесс регистрации можно будет считать завершенным.

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

Есть вероятность того, что Huawei специально усложнила процесс, надеясь на привлечение исключительно китайских специалистов. Но это лишь предположение.

Ну а теперь к самой системе

Да, brand-new операционная система, которую с нуля создали в Huawei!


После получения доступа к SDK запустить его на локальном компьютере не получится. Вместо этого в работу вступает удаленный эмулятор. Все это очень похоже на облачные игры, когда контент воспроизводится где-то там, а на машину игрока поступает лишь видеопоток. Насколько можно понять, сервер с эмулятором находится в Китае. По мнению журналистов Arstechnica, это может быть даже не эмулятор, а реальный телефон с включенным удаленным доступом. Качество картинки 720p. В принципе, для работы достаточно.

После запуска разработчик видит полную копию оболочки EMUI для Android от Huawei. Если посмотреть информацию о системе, везде упоминается Android 10. Компания заявляет, что это просто особенность оболочки, которую не стали менять (вновь выглядит очень странно).


Небольшое путешествие по системе создает полное впечатление, что мы имеем дело именно с Android. Об этом говорят в том числе системные приложения с названиями Android Services Library, Android Shared Library, com.Android.systemui.overlay, Androidhwext и другие. Всего их около 10. А ведь должно быть по-другому, раз уж мы работаем c Harmony OS v2.

Если посетить Huawei App Gallery, которая на деле каталог приложений под Android, то везде и всюду мы видим информацию об Android 10 Q. И ладно бы это была просто альфа- или бета-версия ОС, которая не работает или работает, но плохо. Пример Google Fuchsia и Tizen от Samsung. Есть проблемы, неработающие приложения, ограничения и т.п. Но все же это полноценные ОС. Не оболочки, а созданные с нуля платформы. Если представить, что Huawei полностью скопировала интерфейс Android, то это нужно постараться скопировать все настолько точно, включая системные библиотеки и все прочее.

По мнению журналиста Arstechnica, проблем с выпуском новой ОС в этом году нет. Если это просто доработанный Android, то особых сложностей и не будет. В каталоге приложений знакомый всем софт от Google, Microsoft, Amazon, TikTok, WeChat, Tencent, Baidu, Weibo, Evernote.


Компания Huawei, похоже, просто заменила все приложения от Google, которые не будут работать из-за санкций, собственными. При этом все остальное разработчики даже не постарались сильно изменить. Большинство элементов так и остались неизмененными, это оригинальные Android-элементы, системные приложения и все прочее. Насколько можно понять, все это просто форк Android и ничего более. В целом, с этим все окей, никакого негатива. Но непонятно, почему Huawei не хочет просто признать, что разрабатывает форк Android, а не полноценную ОС.

Еще немного странностей

У HarmonyOS есть Open Source версия, которая называется "OpenHarmony". При этом как раз здесь мы видим полностью оригинальную систему, предназначенную, правда, только для IoT-устройств. OpenHarmony идентифицирует себя как Version 1.0. Здесь используется микроядро LiteOS IoT, а приложения из репозитория не приложения под Android.

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



Вот документация для системы. Она тоже очень-очень странная.

Форк Android хороший вариант для Китая

С технической точки зрения здесь все ясно. С точки зрения ухода от санкций США создание форка Android имеет смысл. Дело в том, что саму ОС компания Huawei может использовать, ей запрещено лишь работать со встроенными в операционку сервисами Google. Здесь все логично для быстрого запуска линейки телефонов, которые можно продавать без ограничений, форка Android с китайскими сервисами вполне достаточно.

Но что странно (да, это слово повторяется по тексту часто), Huawei планирует лицензировать свою ОС. Каким образом это можно сделать с перелицованным Android, неясно. Возможно, речь идет о первой версии Harmony OS, которая не является форком. Но, если и так, Huawei все равно ничего не комментирует. По крайней мере, пока.

Плюс ко всему, Huawei не сможет продавать телефоны с модифицированным Android по всему миру, ведь пользователям будут недоступны приложения от Facebook, Snapchat, Netflix, Hulu, Amazon, Twitter, Roku, SoundCloud, Pandora, Amazon, Uber, Lyft, Tinder, Shazam и т.п. Права на них принадлежат американским компаниям, а значит, использовать софт нельзя. Кроме того, не будет Gmail, Chrome, YouTube, Google Assistant, Google Maps.

Скорее всего, компания будет продавать свои телефоны с модифицированным Android в Китае, а не за рубежом. Если так, то все становится понятно, и шаги компании вполне логичны. Но называть ОС своей разработкой не стоит, это, скорее, просто китайская версия Android примерно такая же, как и версии Linux, о которых мы писали.

Windows 10X, Project Reunion, Windows Core OS Слышали о том, что Microsoft разрабатывала операционную систему нового поколения? Настало время узнать, что плохого и что хорошего это принесёт.


Изображение: Microsoft

Запуск Windows 10X важный шаг для Microsoft, он знаменует собой рождение нового поколения Windows. Об этом на конференции Ignite 2021 много говорил Пэнос Панай, директор по продуктам в Microsoft.

Не секрет, что в этом году Microsoft запускает новую операционную систему. Представители корпорации анонсировали Windows 10X ещё в 2019 году. Система построена на основе Windows Core OS. Это современная модульная программная платформа (именно она управляет гарнитурой дополненной реальности HoloLens 2). Изначально разработчики Windows 10X ориентировались на устройства с двумя экранами (например, складной планшет Surface Neo). Однако впоследствии они добавили оптимизацию графического интерфейса и для устройств с одним экраном.

По мнению авторитетного журналиста Зака Боудена, Windows 10X это ответ на запуск Google Chrome OS (легковесная ОС для сравнительно дешёвых устройств, ориентированная на облачные и веб-приложения). Точно известно, что новая ОС от Microsoft не будет обладать полным функционалом десктопной Windows 10, которую многие используют для работы или гейминга. Поэтому 10X вряд ли когда-нибудь заменит 10-ку. А дизайн Windows 10X претерпел ряд изменений и теперь больше напоминает Windows 8 ARM (Windows RT).

Новое поколение

По сравнению с предыдущими версиями ОС в архитектуре Windows 10X много изменений. Не всё уже существующее программное обеспечение, написанное для более ранних версий Windows, можно будет установить и запустить на ней. Изначально разработчики планировали реализовать нативную поддержку классических Win32-приложений наравне с UWP-приложениями. Но в процессе планы поменялись и задачи усложнились.

В первых релизах не будет нативной поддержки Win32-приложений. Разработчики отложили эту задачу в долгий ящик. Чтобы разрабатывать UWP-приложения под Windows 10X, нужно обращаться к WinRT API. Другой вариант разработка прогрессивных веб-приложений (Progressive Web App, PWA).

В итоге разработчики пришли к тому, что система должна работать примерно как Windows 10 в S-режиме. Только её GUI должен быть более современным и адаптивным. Windows 10X облачно-ориентированная модульная операционная система с повышенной скоростью запуска и обновления. Набор сервисов Microsoft 365 (например, OneDrive для хранения файлов) интегрирован непосредственно в ОС.

Первые устройства с Windows 10X на борту нацелены на образовательный и бизнес-сегмент, где веб-приложения, в отличие от нативных UWP, наиболее востребованы. Но даже при таком раскладе многие пользователи захотят скачивать UWP-приложения из Windows Store, устанавливать их и запускать на новой операционной системе.

Современная разработка под Windows с Project Reunion

Но каким же образом перенести старые приложения на новую ОС? Под Windows написано множество приложений разного типа, и UWP только один из них. А если приложение разработано с использованием Win32 API? Стоит отметить, что таких приложений по-прежнему немало, и они бывают востребованы.


Изображение: Microsoft

В Microsoft достаточно долго думали и наконец придумали единую платформу для разработки под Windows Project Reunion. Разработчики реализовали в ней специальную технологию, позволяющую объединить Win32 API и UWP API. Единая платформа позволяет конвертировать уже существующие классические Win32-приложения в UWP-приложения с минимальными усилиями.

С появлением платформы разработки Project Reunion появилась возможность отделить API старых десктопных приложений и UWP-приложений от кода самой ОС, объединив их в единый Reunion SDK. Это должно облегчить жизнь разработчикам.

Безусловно, Project Reunion не сможет полностью заменить Windows SDK. Проекту и без того предстоит долгий путь развития: портирование API, создание подобия полифиллов, функций-обёрток над комбинациями вызовов новых и старых API для достижения более высокого уровня абстракции.

Project Reunion не подразумевает формирования очередного монолитного SDK: он будет работать по принципу пакетов NuGet, которые могут обновляться без обновления всего SDK. С одной стороны, это позволит заменять полифилы нативными вызовами, с другой стороны, добавлять в SDK новые порции API по мере их готовности. На сегодняшний день можно посмотреть последнюю сборку (0.5), и составить об этом своё представление. Но пока это лишь небольшой набор API и UI-контролов, но уже сейчас можно собрать и упаковать своё приложение в MSIX-установщик.

Одним из главных компонентов Project Reunion стала библиотека Windows-контролов нового поколения WinUI 3.0. Её можно использовать для разработки и Win32-приложений, и UWP-приложений. Библиотека соответствует спецификациям нового дизайна для Windows 10X, а контролы способны адаптироваться и менять свои размеры в зависимости от устройства.

Объединение API для Win32 и UWP должно избавить разработчиков от многих проблем и рисков, связанных с портированием приложений (например, срыв всех возможных сроков из-за непредсказуемого поведения приложения, переписанного под новую платформу).

После выхода .NET 5 Microsoft ещё больше уходит от монолитного .NET Framework в сторону модульного легковесного .NET Core. Теперь .NET 5 заслуживает особого внимания, если вы хотите разрабатывать под Windows 10X. Более того, это даже выгодно, так как приложения, разработанные под Windows 10X запустятся и на других версиях Windows 10. По крайней мере, это обещают в Microsoft.

Напомним, что в Windows Store можно публиковать приложения для всех версий Windows 10. И, как всегда, поможет в этом Visual Studio, которая позволяет собирать, тестировать и паковать приложения под платформы Intel и ARM.

Использование виртуальных рабочих столов в облаке

Не все приложения смогут использовать преимущества Project Reunion или Windows Store. В ближайшие год-два они вряд ли дождуться появления тех API, которые нужны, на самом деле, уже сейчас. Корпоративным клиентам и образовательным учреждениям в этом плане будет легче. Они смогут настроить в облаке виртуальные рабочие столы Windows, чтобы их приложения стали доступны для пользователей. Для работы с GUI на устройствах с Windows 10X можно использовать UWP Remote Desktop. Код при этом будет крутиться на виртуальной машине Microsoft Azure.

Сейчас идёт активная работа над облачным сервисом Cloud PC, который обещает стать усовершенствованной версией Windows Virtual Desktop (по крайней мере, с точки зрения юзабилити). Новый сервис должен стать частью Microsoft 365 и предоставить учебным заведениям и бизнесу простой тариф с фиксированной оплатой за каждого пользователя размещённых в облаке приложений и рабочих столов.

Взглянув на бета-версии, гуляющие по сети, можно предположить, что пользовательский интерфейс сервиса спроектирован в стиле Windows 10. Вероятно, Microsoft запустит Cloud PC одновременно с одной из следующих версий Windows 10X. Скорее всего, тогда мы и посмотрим на него в деле: например, увидим как добавлять свои собственные приложения в образ Cloud PC.

Что делать сейчас

Уже ясно, что и без нативной поддержки классических Win32-приложений будет много интересных причин для перехода на Windows 10X. Максимально эффективно на этой системе будут работать нативные приложения UWP. Возможность запускать (плюс-минус) один и тот же код на ещё большем количестве разных устройств это очень серьёзная причина отказаться от legacy-кода и старых API в пользу современного и (по замыслу разработчиков проекта) более секурного кода.

Пока нельзя предсказать, куда в итоге выведёт орбитальная кривая развития Windows 10X и её спутников, но нам явно стоит включить в свои ближайшие планы знакомство с ней. Миграцию можно начинать уже после выхода первого релиза Project Reunion и появления обратной совместимости с Windows 10 1809. Если же какие-то из ваших пользователей откажутся от этого, то их проекты можно перекинуть на Cloud PC.

Наиболее конъюнктурный вариант пересаживаться сразу на UWP и .NET 5. Именно в эту сторону Microsoft планирует сдвинуть свой сегмент рынка. По мере появления новых API в Project Reunion, привлекательность портирования будет расти. Конечно, на миграцию, дописывание и переписывание может уйти много времени. Но, если вы хотите быть впереди планеты всей, то, начав в ближайшее время (пока ОС не получит широкого распространения), сможете стать одним из первопроходцев.

---

Наша компания предлагает серверы на Windows от 23 рублей в сутки!
Зарегистрируйтесь по ссылке выше или кликнув на баннер и получите 10% скидку на первый месяц аренды сервера любой конфигурации!

Несколько дней назад на Хабре опубликовали новость о том, что Microsoft закрывает свой масштабный проект революционную, как сообщалось компанией, операционную систему Windows 10X. Изначально эта ОС проектировалась для гаджетов с двумя экранами, но потом компания решила расширить количество совместимых платформ, добавив ноутбуки с базовой конфигурацией.

Отказ от этой ОС был неожиданностью для многих, ведь компания несколько раз заявляла, что Windows 10X появится уже в этом году. Но как раз примерно в момент планируемого выхода компания решила все отменить.

Как все начиналось

У Windows 10X было сразу несколько предварительных названий, включая Windows Core OS, Windows Lite и другие. Сначала компания Microsoft начала разрабатывать ее для установки на устройства нового типа с двумя экранами. Слухи об ОС ходили задолго до ее появления, но официальный анонс компания сделала в октябре 2019 года, одновременно с Surface Neo. Это был девайс с двумя экранами, на который и была установлена операционная система.


Разработчики заявили, что операционная система ориентирована на ARM, как до этого было с Windows RT и Windows 10S. Пытались добавить эмуляцию Win32-приложений, но в итоге отказались от этого, так что уже готовые наработки убрали из тестовой версии.

В течение нескольких месяцев СМИ, освещавшие ход разработки двухэкранных систем и самой ОС, называли проект революционным. Но, к сожалению, революции не случилось. Фанфары звучали все тише, а потом музыка и вовсе стихла. Громких заявлений не было слышно до самой отмены релиза Windows 10X.

Что-то пошло не так

Можно сказать, что повторилась история с планшетами Courier. Изначально именно Microsoft, а не Apple начала активно продвигать концепцию планшетов, а Courier был реально инновационным девайсом на момент своего появления. Возможно, у Microsoft ничего и не получилось бы, даже если компания выпустила планшет на рынок. С другой стороны, это могло сработать.

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

Правда, проект создания платформы прожил дольше, чем железо, поскольку Windows 10X решили позиционировать в качестве если не конкурента, то хотя бы аналога Chrome OS. Именно поэтому и была добавлена поддержка архитектуры ARM, чего, например, нет во взрослой Windows 10.

В середине декабря 2020 года сразу несколько интернет-СМИ заявили о том, что разработка Windows 10X закончена и вскоре эта ОС станет доступна для производителей ноутбуков. Речь идет об RTM-версии. Во втором квартале 2021 года ожидалось поступление в продажу устройств с этой платформой. В целом, шансы победить ту же Chrome OS у Windows 10X были, ведь до настоящего момента доля ОС от Google составляет немногим более 1% всего рынка настольных ОС.


У Windows 10X было несколько отличий от Windows 10:

• Меню Пуск не только переименовано в Launcher (оригинальное название Start), но и переформатировано. В него входила строка поиска, выводились недавно используемые документы и приложения. Разработчики изменили интерфейс меню для того, чтобы пользователи могли оперативно запускать задачи.
• Мгновенный выход из спящего режима. После того, как эту возможность добавила Apple в свои ноутбуки, разработчики Microsoft решили использовать моментальный выход из спящего режима и в своей ОС (возможно, это была оригинальная идея).
• Быстрая настройка. Общее меню настроек было разделено на два основных элемента. Один из них, быстрые настройки, включал самые популярные пункты вроде беспроводной связи или языка ввода. Впрочем, нечто подобное есть и в Windows 10.
• Упрощенный интерфейс и отсутствие возможности устанавливать обычные приложения с разных ресурсов только из Microsoft Store.

Неожиданная отмена

Несколько дней назад корпорация выпустила кумулятивное обновление Windows 10 May 2021 Update (21H1). Обычно его выпускают накануне или одновременно с конференцией Build, но на этот раз компания решила действовать более оперативно. И практически сразу же последовало заявление о закрытии проекта Windows 10X.

Большинство важных наработок отмененной операционной системы не пропадут их добавят во взрослую ОС. Для этого будет выпущено специальное обновление Windows 10 Sun Valley, которое вберет в себя все наработки Windows 10X, которые компания сочтет важными. Недавно в сети появился скриншот системы после обновления.


Насколько можно судить, в ОС изменяется Центр действий и уведомлений Windows 10, включая управление меню при помощи пальца (возможность показать или скрыть элементы). Кроме того, будут скруглены углы у некоторых элементов интерфейса.


Вероятно, будут расширены возможности управления при помощи сенсорного экрана и голоса. Какие еще будут нововведения, только предстоит узнать.

Windows 10X не первая и, вероятно, не последняя отмененная ОС от Microsoft

У корпорации Microsoft, как и у многих других компаний, довольно много отмененных проектов, которые изначально считались перспективными. Что касается Windows 10X, это уже третья ОС, которую отменили по той или иной причине.

Первой (из относительно новых) операционных систем, разработку которых решили закрыть, стала Windows RT. Она тоже работала с ARM-процессорами и выполняла практически те же задачи, что и взрослая ОС. Она вышла в релиз, на ее основе разрабатывались устройства, включая планшеты линейки Microsoft Surface и Nokia Lumia. Но в итоге ОС прекратили развивать.

В 2017 году компания объявила о скором выходе Windows 10S упрощенной версии Windows 10. Здесь все было похоже на текущую ситуацию. Система была рассчитана на ARM, Windows 32-приложения запускать было нельзя, это была ОС для устройств базового уровня. Но она так и не вышла в свет, ее наработки использовали для развития основной линейки Windows 10.

Причины, по которым были отменены как эти ОС, так и Windows 10X, компания не раскрывает. Вполне может быть, что руководство отдела, занимающегося разработкой упрощенной операционной системы, пришло к выводу, что силы и ресурсы компании лучше не распылять, а сфокусировать на Windows 10.

Хорошие новости для владельцев хромбуков вышел релиз Chrome OS 85. База этой операционной системы ядро Linux, плюс системный менеджер upstart, сборочный инструментарий ebuild/portage, открытые компоненты и браузер Chrome 85.

Chrome OS 85 доступна для большинства актуальных моделей Chromebook. Система включает многооконный интерфейс, рабочий стол и панель задач. Она получила ряд обновлений и новых функций. Подробнее обо всем под катом.

Функция Wi-Fi Sync для владельцев нескольких Chromebook

Wi-Fi Sync отвечает за хранение настроек беспроводной сети на нескольких устройствах. При первой настройке Wi-Fi данные сохраняются в личном профиле пользователя Chromebook. Далее, при входе в профиль с другого ноутбука от Google, настройки беспроводной сети будут автоматически перенесены на устройство. Таким образом, Wi-Fi Sync идеальный вариант для пользователей с несколькими Chromebook

Поиск настроек

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

Новый регулятор громкости

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

Обновление приложения Camera

В приложение Camera для Chrome OS 85 добавлены функции управления видеозаписью: приостановление и возобновление съемки, создание скриншота кадра. Формат видео MP4. Роликами можно поделиться с друзьями или отредактировать в сторонних приложениях.

Улучшение работы с принтерами

В интерфейсе вывода на печать можно просмотреть завершенные задачи и управлять очередью ожидающих печати документов. Для принтеров Hewlett-Packard, Ricoh и Sharp появилась опция ограничения доступа к печати при помощи PIN-кода.

И кое-что еще

В режиме голосового чтения выделенных областей (Select to Speak) появилась опция для затенения части экрана вне выделенной области.

Добавлена поддержка стандартных экранных жестов в режиме рукописного ввода.

Технические подробности о новой системе можно узнать из статьи Эмиля Великова (Emil Velikov), который отвечает за подготовку выпусков Mesa. Статья посвящена, в первую очередь, устройству графического стека Linux, его использованию в Chrome OS и работе по улучшению качества программного рендеринга. В частности, в статье говорится о том, что для избавления от привязки к X11 в прослойке Ozone используется OpenGL/GLES и EGL. Например, EGL-расширение EGL_MESA_platform_surfaceless, которое дает возможность работать с OpenGL или GLES, выполняя отрисовку в область памяти без необходимости задействования компонентов для интеграции с экранной системой и без привлечения кода Wayland, X11 и KMS.

Новый релиз будет распространяться на Chromebook в течение нескольких дней. Энтузиасты уже подготовили сборки Chrome OS 85 для компьютеров с процессорами x86, x86_64 и ARM. Исходный код доступен для всех, распространяется он под свободной лицензией Apache 2.0.