Операционные системы обычно остаются за кадром нашей жизни, но именно они управляют тем, что мы держим в руках каждый день. За интерфейсом телефона скрыты идеи, которые не должны исчезнуть, как исчезло множество технологий древности, передаваемых из уст в уста. Об инструментах разработчика и о философии открытого кода Алексею Федосееву рассказывает Алексей Андреев из компании «Открытая мобильная платформа», разработчик отечественной ОС «Аврора».
Часть 1. О мобильной операционной системе
— Алексей, давай начнем с того, с какими задачами ты сталкиваешься на работе. — Компания «Открытая мобильная платформа» существует уже без малого десять лет и ориентируется в первую очередь на бизнес-заказчиков. Основной продукт — мобильная ОС «Аврора». Ее используют компании, которые заинтересованы разворачивать автоматизацию на своих мощностях в доверенной среде. Например, в РЖД для обходчиков путей или для почтальонов в Почте России поддерживают собственные службы и парки мобильных устройств с ОС «Аврора». Устройства выдают сотрудникам для соблюдения требований безопасности. Важным этапом для компании также была Всероссийская перепись населения, где использовались планшеты с ОС «Аврора».
Постепенно развились не только сама операционка, но и продукты вокруг нее: от магазинов приложений и решений по администрированию большого числа устройств до механизмов безопасной загрузки и собственной доверенной вычислительной среды «Аврора TEE», это позволяет создавать самостоятельные решения, не полагаясь на сторонние продукты.
— Это похоже на то, как Android запрашивает разрешение, чтобы предоставить доступ приложениям к камере или вашему местоположению? Такими вещами ты занимаешься? — Да, в том числе. Задачи часто возникают в связи с безопасностью данных и требованиями к предсказуемости управления системами. Вопрос в том, как это сделать удобным для разработчика, сохраняя его самостоятельность. Здесь нам приходится работать в тесном взаимодействии с партнерами, мы можем себе это позволить, работая более тонко с ОС, которую полностью разрабатываем сами. Сам я в команде, занимающейся вопросами экосистемы вокруг ОС «Аврора».
— То есть твоя работа, по сути, на границе между теми, кто пишет саму операционную систему, ее ядро, и всеми, кто создает новые приложения? — Все так. Но эта граница довольно широкая. Помимо ядра в состав операционки входят разные вспомогательные службы, графическая оболочка для приложений, инструменты разработчика и тому подобное. Моя активность сейчас ближе к сторонним приложениям, это вне самой операционной системы. Для экосистемы важно проходить путь сторонних разработчиков и упрощать интеграцию в новую среду. К примеру, когда кто-то хочет выстроить свое решение: собственный протокол VPN или службу push-уведомлений, нужно понимать, с какими проблемами может сталкиваться разработчик, не погруженный во внутреннее устройство новой мобильной ОС.
— Кстати, расскажи про связь с операционной системой GNU/Linux. В ней же есть много собственных инструментов безопасности. А «Аврора» во многом базируется на Linux? — Да, по составу мы близки к дистрибутивам Linux. Но мобильные ОС, в том числе Android или iOS, имеют свою специфику.
Если мы посмотрим на настольный Linux, то он довольно фрагментированный. В фундаменте можно увидеть определенный слой абстракций — например, соответствие POSIX, стандартную библиотеку libc. Даются гарантии, предсказуемость, что интерфейсы, вызовы, используемые в программах, будут плавно меняться со временем.
Но если мы говорим про какую-то логику уровнем повыше, актуальную для мобильных ОС, например, про механизмы изоляции приложений и запрос разрешений, про доступ к комплексному набору камер, про библиотеки для работы с видеоконференциями, NFC, GPS, GSM, логику экономии заряда батареи, то готовых решений может либо просто не быть в Linux-дистрибутивах, либо может быть несколько конкурирующих решений, далеких от какой-то стандартизации. Они могут сильно отличаться от дистрибутива дистрибутиву (например, была ли это инициатива от Red Hat или от Canonical). Либо вообще какую-то часть задач надо решать уже на уровне браузера — там уже со своими компромиссами.
— Получается, что вам, как создателям мобильной операционной системы, нужно этот «зоопарк» сильно уменьшить и сделать для разработчика приложений четкий и понятный набор API? — Да, причем поддержать не только базовую доверенную среду и службы, специфичные для мобильной области, а также поддержать само железо.
Далеко не всегда для мобильного устройства существует поддержка со стороны Linux, например, без закрытых «драйверов» от Android на каком-то конкретном устройстве может не работать камера или модем для звонков и интернета.
Есть разные способы обходиться с этим ограничением. Например, сообщество postmarketOS занимается реверс-инжинирингом доступных на рынке устройств, чтобы обеспечить полноценную поддержку Linux на своих мобильных устройствах. У них пока нет смартфона, в котором все компоненты работают на Linux, но результаты все равно впечатляют.
Другой яркий пример: Steam Deck от Valve, — по сути, им тоже нужно мобильное переносимое устройство, и оно делается на более доступной для Linux платформе (ближе к ПК, как ноутбуки). Но там тоже есть особые требования к среде исполнения: для запуска лицензионных продуктов и защиты от «читов» (от злоупотребления игроков). Интересно, что у них получится в будущем.
Часть 2. О языках программирования и других инструментах системной разработки
— Спасибо, чуть-чуть разобрались. Расскажи теперь о тех инструментах, которые ты используешь. Операционная система — это значит языки C и C++? gcc? Какой вообще набор инструментов (toolchain) нужен для подобной системной разработки? Мобильные устройства — это чаще всего ARM-архитектура. Сейчас появляются новые, в будущем может распространиться RISC-V. То есть в основном это gcc и кросс-компиляция: ты сидишь на обычном PC и компилируешь проект под другую архитектуру. В основе тут открытые инструменты. Например, проект Linaro для кросс-компиляции под ARM. Мы дорабатываем их под себя. Есть также внутренние репозитории RPM-пакетов для сборки образа, а готовый SDK доступен на портале разработчиков вместе с документацией.
— Ага, понятно. Раз уж мы коснулись вопроса языков для системной разработки, скажи свое мнение по теме, которую многие обсуждают, — какой будет следующий язык системного программирования? Скоро C уйдет в прошлое? Меняется ли что-то в этой области или по-прежнему каждый системный программист должен знать С++? К примеру, рассматриваете ли вы Rust? — Мне кажется, меняется. Но тут важно учитывать предвзятость того, кто отвечает. Мне, например, самому С++ чуть симпатичнее, чем С, когда работаем с графикой и ООП, с исходниками Qt. Я с ядром Linux и его подсистемами, с модулями, скорее, на «вы». Минималистичность С меня не так сильно привлекает. Наверное, поэтому Rust меня тоже не сильно привлекает на замену плюсов, у меня нет к С++ сильных претензий. Но при этом я вижу, что как будто бы практика меняется. Мне нравится энтузиазм, хоть над этим все смеются, что любители раста все себе переписывают. Для этого надо так или иначе хорошо погружаться в вопрос. Но пока не было проекта, через который я бы заинтересовался сам. Если я лет двадцать потрачу на С++ и не познаю его глубин, а мне уже предлагается еще лет двадцать потратить на Rust… А потом и он станет таким же зрелым и неповоротливым языком, обрастет наследием, которое будет тянуть назад. Но я не думаю, что это какая-то временная штука, Rust действительно может закрепиться, это вполне живое сообщество.
Вот, например, я в свое время интересовался дистрибутивами Linux. Про это есть много холиваров. Новички любят перебирать дистрибутивы, делать такой «дистро-хоппинг», это когда ты пробуешь все дистрибутивы подряд. И я застал время, когда вот все смеялись над Arch Linux, мол, чего все пытаются проповедовать любовь к этому Arch Linux, он никому не нужен и так далее. А мне он понравился, я в ArchWiki очень много для себя очерпнул как специалист. Сейчас Arch Linux вполне закрепился в мире дистрибутивов. Как вспоминали, Valve в своих приставках Steam Deck его как базовый образ используют. Получается, он вырос из каких-то шуточных обсуждений и приколов, стал более зрелым. Наверное, еще не таким зрелым, как Debian, там целая книга документов о том, как быть ментейнером.
— А расскажи про свой рабочий стол, раз мы про это вспомнили. Ты говорил про кросс-компиляцию, а сам на Linux сидишь? — Да, BTW I Use Arch. Системными администраторами предлагается еще Ubuntu, а также отечественная ОС «Альт» проверяется командой тестирования на совместимость с новыми выпусками «Аврора SDK».
— Дальше серия классических вопросов. KDE или Gnome? У вас в связи с работой на Qt KDE, наверное, обязательный? — Нет, не обязательный. И у нас есть ребята, которые прям хорошо разбираются в инфраструктуре Gnome. Но это непринципиально, в целом инструменты подбирают под задачи. Для меня это KDE, как уже понятно по моей любви к Qt.
— Понятно. А какие еще ключевые приложения десктопного Linux для тебя делают рабочую среду удобной? И еще вопрос — Vim, Emacs или какой-то еще редактор, в котором ты кодишь? — Vim я пользуюсь, когда нужно что-то быстро сделать, например, поправить что-то на сервере. Но я в нем не живу, у меня нет какого-то хитрого набора конфигов. Вообще, к консольным утилитам у меня довольно мало требований: у меня нет любимого shell-а, который мне все подсвечивает, я как-то меньше в это погружен. Мне нравится оболочка KDE: как она с окнами справляется, ее параметры по умолчанию. Весь набор KDE-шных инструментов от проводника до терминала сильно-сильно мне нравится. Но сейчас очень много инструментов ушли в веб. Например, я пишу в Markdown-редакторе, который представляет собой клиент-серверное приложение, это редактор в браузере. А весь код, связанный с приложениями, я пишу в Qt Creator. Еще использую VS Code, если нужно попробовать что-то новое, подсмотреть какие-то плагины. Получается такая тройка с возрастанием сложности: Vim, Qt Creator и VS Code.
— А если говорить про системы сборки? К примеру, CMake или встроенные средства Qt? Что ты предпочитаешь использовать? — Если это программа на C++, то CMake, да. Для Flutter-разработки есть своя инфраструктура. В Kotlin — своя. В общем, это сильно зависит от фреймворка и предпочтений разработчика. Нашим ребятам, которые ближе к C, CMake не очень интересен. Им интересен Meson и другие инструменты сборки на Python. Мне в принципе CMake норм. Ну его сложно любить, потому что он такой старомодный.
— Понятно. Спасибо. Получается, что основная твоя работа связана с написанием кода и его тестированием, правильно? — Сейчас моя основная работа связана скорее с организацией работы других, с постановкой задач в Jira, поддержанием базы знаний в актуальном состоянии, всякие такие организационные работы, код-ревью. Это все веб-инструменты. Тот же GitLab сводится к работе в вебе.
— Это как блокнот — главный инструмент менеджера? — Ага. Кстати, четвертый редактор, который я не назвал, — это простой текстовый редактор с подсветкой синтаксиса. Вот в KDE-шной среде это KWrite, но такие во всех оболочках есть. Иногда это очень удобно. Вообще, не бывает каких-то волшебных инструментов. У меня нет суперспециальных задач, требующих какого-нибудь одного-единственного САПР-а. И мне приходится в основном тексты редактировать. Люблю markdown и WYSIWYM-редакторы (никак не WYSIWYG). Например, в качестве web-версии использую HedgeDoc, развернутый для себя.
— А все-таки есть что-то, выходящее за рамки набора стандартных инструментов? Может, какие-то эмуляторы? — С ходу не приходит в голову что-то совсем нестандартное. Но разные службы могут быть настроены под нужды компании. Например, служба для сборки готовых образов. Сами компоненты свободные (OBS, Imager), но в устройство готовой системы я сейчас не погружен и пользуюсь ее результатами для получения экспериментальных версий прошивок. Эта служба непроста тем, что поддерживает множество конфигураций и устройств.
Если мы говорим про какой-нибудь эксперимент, скажем, с носимой электроникой, можем использовать другие open source инструменты близкие к робототехнике. Можем на старте использовать библиотеки на Arduino, а дальше уже заморочиться с RTOS-операционкой для ESP32. Это все открытые инструменты, тут нет ограничений, и все зависит от вкуса и выбора разработчика. У нас используются и проприетарные инструменты, если они лучше подходят командам. Например, коллеги-дизайнеры используют Figma.
Часть 3. Об особенностях разработки с открытым кодом
— Раз мы подошли к теме open-source, давай обсудим специфику разработки свободных и открытых программ. Расскажи немного, что тебя привлекает в этом подходе? — В первую очередь я бы сказал об опенсорс-лицензиях. Вообще, коммерческой компании интересны скорее пермиссивные лицензии (без жестких требований по использованию кода, даже в коммерческих целях — прим. А. Ф.), потому что ты можешь использовать этот код, закрывать, монетизировать. Распространение собственных разработок под пермиссивной лицензией дает возможности для эффективной работы с партнерами, например, у нас в компании так публикуются примеры разработки приложений под ОС «Аврора» и некоторые библиотеки, которые крайне важны разработчикам экосистемы «Аврора». Это позволяет сократить срок написания приложений, избежать каких-то ошибок.
Мне лично интересно смотреть за тем, как вообще развивается опенсорсная мысль, в том числе и свободное ПО. Для личных проектов меня вполне устраивают свободные лицензии. Но чем больше ты окунаешься в интересы компаний, интересы конкретных людей, тем картина мира усложняется. Иногда сдвоенные с коммерческой копилефтные лицензии выбираются компаниями, чтобы получать средства на существование (например, MySQL). Иногда пермиссивные, чтобы выигрывать в войне стандартов, закрепиться стандартом де-факто в своей области. В общем, кажется, что внутри самого движения есть много разных ответвлений, к которым я еще только формирую свое отношение.
Есть и забавные случаи с лицензиями. Например, шуточные лицензии вроде одной, в которой написано, что код разрешается использовать кому угодно, всем людям мира, только не Столлману. Ричард Столлман — основатель движения свободное ПО, и у этого автора лицензии, похоже, еще в молодости пошла трещина в отношениях со Столлманом. Есть интересные примеры, когда код доступен, но в текст лицензии намеренно добавляют ругательства, чтобы усложнить работу корпоративным юристам, которые хотели бы в компании это легально использовать. Еще друзья рассказывали, что в недрах исходников старых версий Mac OS от Apple была специальная строчка кода, что-то в духе стишка на тему «не воруйте нашу работу», которая являлась ключом для запуска и требовалась для работы на стороннем оборудовании. Apple в судах пыталась зарегулировать запрет на использование этой строчки как своей интеллектуальной собственности, чтобы помешать нелицензионным запускам. В общем, это мир довольно богатый.
— Понятно, что вопрос лицензий лежит в основе открытой разработки, все это четкое соблюдение прав и так далее. А что еще, помимо лицензий, отличает проприетарную (результаты которой принадлежат компании, а не сообществу) и свободную разработку? — Первое, что приходит в голову, — это доброжелательность, открытость, дух научного сообщества. Очень приятное ощущение, когда ты участвуешь в международном взаимодействии, когда ты гражданин мира, даже если работаешь в очень узкой области, где всего три заинтересованных человека, но тебя благодарят. Есть знаменитый комикс «XKCD № 1228» — шуточная пародия на миф про Прометея, в котором боги его ругают за то, что он украл огонь и отдал его людям. А Прометей им отвечает: я же не украл, я только поделился, огонь же у вас остался. В открытом сообществе такая же атмосфера, ты чем-то поделился, но и сам это не потерял. На самом деле там тоже есть свои передряги, это все похоже на остальной мир.
— А что ты можешь сказать про особый стиль разработки? Есть что-то такое, что выделяет разработчика свободных программ? — Вообще, если человек профессионал, и в проприетарном, и в опенсорсном сообществе виден и он сам, и действия, которые он совершает, и инструменты, которые он использует. Профессиональные разработчики всегда найдут общий язык, смогут оценить друг друга.
— Насколько все изменилось за последние три года? Мы много слышим про санкции, блокировках разработчиков. Чувствуется ли какая-то напряженность в сообществах открытого ПО или по-прежнему продолжается горизонтальное взаимодействие? — Я могу сказать про пример Qt, которая разрабатывается в Qt Company. Понятно, что это коммерческая компания в юрисдикции определенной страны, они вынуждены соблюдать законы и следовать санкциям. Но исходники никак не блокировались, и, что касается open source взаимодействия, никаких ограничений не произошло. Я бы не сказал, что почувствовал какой-то стресс в этом плане. Хотя конфликтные ситуации встречались. Вообще, нашу компанию это затрагивает слабо, потому что у нас вся инфраструктура развернута своя — есть собственные зеркала кода и так далее.
— Все-таки в чем для тебя главная ценность открытого кода? — Думаю, переживания, общие с темой свободного ПО, я заметил за собой еще в начальной школе, когда почти ничего не знал о компьютерах. Учительница читала нам отрывки из «Слова о полку Игореве» и рассказывала о харалуге — дамасской стали, технология изготовления которой была утеряна, потому что передавалась только из уст в уста. Я помню свои переживания, что меня это очень впечатлило тогда, — оказывается, знание может быть утеряно. Благодаря open source потерять знание невозможно — в какой-то момент Nokia не справилась со своей мобильной ОС, но все свое наследие оставила под открытой лицензией, а теперь я им пользуюсь.
Часть 4. Обучение программированию
— Давай поговорим о пути будущего разработчика. Мы с тобой говорили про системную разработку, и, кажется, что она уступает в популярности другим направлениям вроде веба, Python, Node.js. При этом мы видим на примере популярной Arduino-разработки, что культуре низкоуровневого программирования совсем не учат, перестали считать байты и так далее. Можешь ли ты подсказать какой-то особый путь именно в системную разработку? — Я слышал, что современному школьнику и студенту легко зависнуть в прикладной разработке и потерять интерес к самим инструментам и движкам. Но я не вижу в этом ничего страшного. Я здесь поделюсь собственным опытом. Когда я был школьником, мне было интересно делать какие-то моды и патчи к играм — добавить свою машину в GTA или смоделировать для Counter-Strike карту своей квартиры. Когда я открыл для себя Linux, интересовался украшательствами системы, как настроить под себя интерфейсы. Мне хотелось больше всего контролировать, а это потребовало компетентности, погружения вглубь — к конфигам, тому, как работает система. Здесь, кстати, очень помогают разобраться вики-порталы открытых проектов. Наверное, сейчас время чуть изменилось, когда я знакомился с миром разработки у меня был интернет и компьютер похуже, не было лекций на YouTube. Мне кажется, нет ничего страшного в том, чтобы начинать «сверху» и постепенно разбираться, может быть, зависнуть в каких-то дебрях. Здесь open source очень помогает, потому что ты можешь познакомиться с кодом, его историей.
— То, что ты рассказываешь, похоже на то, что называют «хакерский путь», когда ты берешь какую-то вещь и начинаешь разбираться, как она устроена, как работает. Я по себе помню и другой путь — я в детстве читал просто подряд книжки по программированию. Но, кажется, это сейчас не очень распространено? — Кстати, когда я был еще в начальной школе, меня очень привлекали энциклопедии, в которых были рисунки, как все устроено. Но в какой-то момент относительно техники я не пошел по этому пути. Может, был кризис с литературой или не было хорошего наставника, который посоветовал бы нужную книжку или дал хорошую вводную. Вообще, этот большущий пласт технического наследия тяжело поднять самому без наставника. Я думаю, что эта картина может поменяться, если вузы найдут более удачный способ передавать актуальные знания из корпорации. Сейчас появилась система быстрых курсов по программированию, которые все ругают, они правда довольно противоречивые. Но, может быть, это поможет как-то продвинуться. Если ты приходишь в вуз, и тебе интересно рассказывают хорошие преподаватели, то можно сократить много времени.
— А правильно я понимаю, что самое распространенное, доступное всем устройство, а именно мобильный телефон, — невероятно сложное и имеет множество «заборов», ограничений? В том числе специально, чтобы хакер или разработчик не смогли забраться куда угодно? Ты же именно этим и занимаешься? Как такие «запечатанные» устройства реверсить и изучать? — Да-а. Вообще, есть банальный ответ. Он в том, что у тебя все равно не получится правильно съесть этого «слона» сразу. Даже если ты в какой-то момент начинаешь изучать computer science, не получается сходу красивый образ, не складывается вся картина слоев сложной архитектуры. И в этот момент помогает как будто бы поиграться со всем подряд и с простыми инструментами начать прямо с азов: что такое транзистор. А потом с другого места: попробовать свой предыдущий телефон, который лежит без дела, помучить как-то. Например, разблокировать загрузчик. Или починить на нем Type-C разъем. И так далее.
— Завершая наш разговор, какое напутствие ты можешь дать будущим системным разработчикам? — Я бы посоветовал не бояться делать первые шаги неправильно. И не пытаться выбрать себе область на всю жизнь с первого класса, особенно если ты еще не нашел ее. Если нашел, замечательно, но если не нашел — вообще ничего страшного. Я сам в какое-то время думал заниматься монтажом видео и не связываться с программированием. Если ты не знаешь, что хочешь, надо просто все пробовать, перебирать. И общаться побольше, наверное, не только с киберфизиками, но и с кибергуманитариями тоже, а также с медиками, художниками, просто смотреть и искать, что нравится.