Идеальная ОС, часть2: переосмысление операционных систем для десктопа
Нам нужна современная рабочая станция» Нажмите, для открытия спойлера | Press to open the spoiler «
Итак, теперь мы выходим на теоретический уровень. Предположим, у нас действительно есть ресурсы и способ обеспечить (или игнорировать) обратную совместимость. Предположим, мы действительно можем создать нечто, чтобы по-другому спроектировать десктоп для современных методов работы. Как мы это сделаем?
Для начала нужно избавиться от всего, что не справляется со своими задачами.
- Традиционные файловые системы иерархические, с медленным поиском и не хранят по умолчанию все необходимые нам метаданные.
- Все межпроцессные взаимодействия. Существует слишком много способов коммуникации между программами. Каналы, сокеты, общая память, RPC, вызовы ядра, drag-and-drop, копипаст.
- Интерфейсы командной строки не соответствуют современному использованию приложений. Мы просто не можем всё делать в чистом тексте. Я бы хотел перенаправить свой видеозвонок по Skype в сервис видеоанализа во время разговора, но я реально не могу запустить видеопоток через awk или sed.
- Оконные менеджеры на традиционных десктопах не следят за контекстом или контентом и не контролируются другими программами.
- Нативные приложения слишком тяжеловесны, их долго разрабатывать и они живут в бункерах.
Так что у нас остаётся? Немного. У нас осталось ядро и драйверы устройств. Мы можем держать надёжную файловую систему, но она не будет доступна для конечных пользователей или приложений. Теперь давайте добавим обратно некоторые элементы.
»» Нажмите, для закрытия спойлера | Press to close the spoiler «« База данных документов» Нажмите, для открытия спойлера | Press to open the spoiler «
Начнём с общей для системы базы данных документов. Не будет ли проще создать новый почтовый клиент, если база данных уже готова? UI будет состоять всего из нескольких строчек кода. В реальности, многие обычные приложения — это всего лишь текстовые редакторы в сочетании с запросами данных. Возьмите iTunes, адресную книгу, календарь, уведомления, сообщения, Evernote, список дел, закладки, историю браузера, базу паролей и менеджер фотографий. Каждая из этих программ оснащена собственным уникальным хранилищем данных. Столько впустую потраченных усилий и помех для взаимодействия!
BeOS доказала, что файловая система с базой данных действительно может работать и обеспечивает невероятные преимущества. Нам нужно её вернуть.
У файловой системы с БД документов много преимуществ перед традиционной файловой системой. Не только «файлы» существуют более чем в одном месте и становятся легко доступны для поиска, но гарантированное наличие высокопроизводительной БД намного облегчает создание приложений.
К примеру, возьмём iTunes. Он хранит mp3-файлы на диске, но все метаданные находятся в закрытой базе данных. Наличие двух «источников правды» создаёт массу проблем. Если вы добавляете на диск новую песню, то нужно вручную указать iTunes заново просканировать её. Если хотите разработать программу, которая работает с базой данных песен, то придётся осуществить реверс-инжиниринг формата iTunes DB и молиться, чтобы Apple не изменила его. Все эти проблемы исчезают при наличии единой системной базы данных.
»» Нажмите, для закрытия спойлера | Press to close the spoiler «« Шина сообщений» Нажмите, для открытия спойлера | Press to open the spoiler «
Шина сообщений станет единым способом межпроцессных взаимодействий. Мы избавляемся от сокетов, файлов, каналов, ioctrl, общей памяти, семафоров и всего остального. Все коммуникации только через шину сообщений. Мы получаем единое место для управления безопасностью и создания множества интересных функций через грамотное проксирование.
В реальности некоторые из видов коммуникации всё-таки останутся как опции для приложений, которым они необходимы, вроде сокетов для браузера, но все коммуникации с системой и между приложениями идут через общую шину.
»» Нажмите, для закрытия спойлера | Press to close the spoiler «« Компоновщик» Нажмите, для открытия спойлера | Press to open the spoiler «
Теперь мы можем добавить компоновщик — оконный менеджер, который по-настоящему работает с 3D-поверхностями, преобразует координаты и контролируется через сообщения по шине. Большую часть того, что делает типичный менеджер, вроде размещения окон, наложения уведомлений и определения, какое окно активно, на самом деле могут делать другие программы, которые просто присылают сообщения в компоновщик, а он уже выполняет реальную работу.
Это значит, что компоновщик будет тесно интегрирован с графическим драйвером, это важно для обеспечения высокой производительности. Ниже показана схема Wayland — компоновщика, который когда-нибудь станет работать по умолчанию в Linux.
Приложения выводят графику на экран, запрашивая поверхность у компоновщика. Завершив вывод графики и при необходимости обновления они просто отправляют сообщения: пожалуйста, перерисуй меня. На практике у нас, вероятно, будет несколько типов поверхностей для 2D- и 3D-графики, а может и для необработанного видеобуфера. Важно то, что в конечном счёте именно компоновщик контролирует всё, что появляется на экране, и когда. Если одно приложение сходит с ума, компоновщик может подавить его вывод на экран и гарантировать, что вся остальная система нормально работает.
»» Нажмите, для закрытия спойлера | Press to close the spoiler «« Приложения становятся модулями» Нажмите, для открытия спойлера | Press to open the spoiler «
Все приложения превращаются в маленькие модули со всеми коммуникациями через шину сообщений. Полностью. Больше никакого доступа к файловой системе. Никакого доступа к аппаратному обеспечению. Всё только в виде сообщений.
Если хотите воспроизвести mp3-файл, то отправляете сообщение play в сервис mp3. Вывод графики на экран через компоновщик. Такое разделение обеспечивает безопасность системы. В терминологии Linux, каждое приложение станет полностью изолировано через разрешения пользователя и chroot, возможно, вплоть до контейнеров Docker или виртуальных машин. Здесь нужно проработать много деталей, но всё решаемо уже сегодня.
Модульные приложения будет гораздо легче разрабатывать. Если база данных — это единственный источник правды, то не нужно делать много работы по копированию данных в память и обратно. В примере с аудиоплеером поле поиска не будет загружать данные и проводить фильтрацию для отображения списка, оно просто определяет запрос. Список затем привязан к этому запросу, а данные появляются автоматически. Если другое приложение добавляет в базу данных песню, которая соответствует поисковому запросу, то UI плеера автоматически обновляется. Это всё делается без каких-либо дополнительных усилий со стороны разработчика. «Живые» запросы с автообновлением сильно облегчают жизнь и они более надёжны.
»» Нажмите, для закрытия спойлера | Press to close the spoiler «« Переделка приложений» Нажмите, для открытия спойлера | Press to open the spoiler «
На такой базе мы можем создать всё, что нам нужно. Однако это также означает, что нам придётся переделывать всё с нуля. Высокоуровневые конструкции поверх БД сильно упростят этот процесс. Посмотрим на несколько примеров.
Электронная почта. Если разделить стандартный почтовый клиент на GUI и сетевые модули, которые общаются исключительно через сообщения по шине, то разработка программы станет намного проще. GUI не должен ничего знать о почте Gmail или Yahoo, или как обрабатывать сообщения об ошибках SMTP. Он просто ищет в БД документы с указанным типом "email". Когда GUI хочет отправить сообщение, то назначает ему свойство outgoing=true. Простой модуль составит список всех исходящих почтовых сообщений и отправит их по STMP.
Разделение почтового клиента на компоненты значительно облегчает замену отдельных его частей. Вы можете разработать новый фронтенд за полдня, и не придётся переписывать сетевые модули. Вы можете разработать спам-фильтр вообще без пользовательского интерфейса, он просто сканирует входящие сообщения, обрабатывает их и помечает подозрительные сообщения тегом «спам». Он не знает и не заботится о том, как отображается спам в GUI. Он просто хорошо делает одну вещь.
Почтовые фильтры могут делать и другие интересные вещи. Например, вы отправили своему боту по почте команду play beatles. Крошечный модуль сканирует входящую почту и отправляет другое сообщение модулю mp3 для воспроизведения музыки, а затем помечает письмо как удалённое.
Когда всё превращается в запросы к БД, то вся система становится более гибкой и настраиваемой.
»» Нажмите, для закрытия спойлера | Press to close the spoiler «« Командная строка» Нажмите, для открытия спойлера | Press to open the spoiler «
Знаю, я раньше говорил, что мы избавимся от командной строки. Беру свои слова обратно. Мне действительно иногда нравится командная строка как интерфейс, меня беспокоит только её чисто текстовая природа. Вместо выстраивания цепочек CLI-приложений с текстовыми потоками нужно нечто более функциональное, вроде сериализованных потоков объектов (как JSON, но более эффективных). Вот тогда у нас появится настоящая сила.
Рассмотрим следующие задачи:
Я хочу использовать ноутбук как усиленный микрофон. Я говорю в него, а голос звучит из колонок Bluetooth в другом конце комнаты.
Как только я публикую твит с хештегом #mom, его копия должна отправляться по электронной почте моей маме.
Я хочу использовать iPhone в качестве микроскопа, закреплённого на стойке из конструктора «Лего». Он транслирует картинку на ноутбук, где у меня управление — кнопки для записи, паузы, приближения и ретрансляции прямого эфира на YouTube.
Я хочу сделать простой байесовский фильтр, который реагирует на почтовые сообщения от «Энергосбыта», добавляет тег «коммунальные услуги», делает запись на веб-сайте, извлекает из письма сумму и дату платежа и добавляет запись в мой календарь.
Каждая из этих задач концептуально проста, но только подумайте, сколько кода придётся написать, чтобы реализовать это сегодня. С интерфейсом командной строки на потоках объектов каждый из этих примеров укладывается в скрипт из одной или двух строчек.
Мы можем осуществлять и более сложные операции, вроде «Найти все фотографии, сделанные за последние четыре года в радиусе 80 км от Йосемитского национального парка с рейтингом 3 звезды или выше, изменить их размер на 1000px по длинной стороне, закачать в альбом Flickr под названием «Лучшее из Йосемите» и поставить ссылку на альбом на Facebook. Это можно будет сделать встроенными инструментами, без дополнительного программирования, просто соединив несколько примитивов.
Вообще-то Apple создала подобную систему. Она называется Automator. Вы можете в графическом интерфейсе создавать мощные рабочие процессы. Система никогда не рекламировалась, а сейчас убирают привязку к Applescript, на которой всё работает. Недавно всех сотрудников группы Automator перевели в другие команды. Эх…
»» Нажмите, для закрытия спойлера | Press to close the spoiler «« Семантические сочетания клавиш по всей системе» Нажмите, для открытия спойлера | Press to open the spoiler «
Теперь, после переделки мира, чем займёмся?
Сервисы доступны во всей системе. Это означает, что мы можем запустить единый сервис, где пользователь может назначать сочетания клавиш (keybindings). Это также означает, что у сочетаний клавиш появится более глубокий смысл. Вместо указания на функцию конкретной программы они указывают на сообщение о команде. Во всех приложениях, которые работают с документами, могут быть команды «Создать новый документ» или «Сохранить». Сервис сочетаний клавиш будет отвечать за превращение control-S в команду «Сохранить». Я называю это семантическими сочетаниями клавиш (semantic keybindings).
С помощью семантических сочетаний клавиш будет гораздо легче поддерживать альтернативные способы ввода. Скажем, вы разработали причудливую кнопку на Arduino, при нажатии на которую звучит какая-то фраза. Вам не нужно писать специальный код для неё. Просто укажите Arduino отправлять событие о нажатии кнопки, а затем привяжите к этому событию аудиофайл в редакторе сочетаний клавиш. Превратите цифровой горшок в кастомное колёсико прокрутки. UI теперь изменяется как угодно.
В этой области ещё необходимы некоторые исследования, но мне кажется, что семантические сочетания клавиш упростят разработку скринридеров и других программ для облегчения доступа.
»» Нажмите, для закрытия спойлера | Press to close the spoiler «« Окна» Нажмите, для открытия спойлера | Press to open the spoiler «
В нашей новой ОС любое окно стыкуется как вкладка к другому окну. Или к боковой панели. Или к чем-нибудь ещё. Независимо от приложения. Здесь большая свобода для экспериментов.
В старой MacOS 8 была разновидность окон-вкладок, по крайней мере, в приложении Finder, которые можно было пристыковать к нижнему краю экрана для быстрого доступа. Ещё одна классная вещь, которую выбросили при переходе на Mac OS X.
На скриншоте внизу пользователь приподымает границу окна, чтобы посмотреть, что там внизу. Это очень круто!
Это был пример из научной статьи «Ametista: мини-набор для изучения новых способов управления окнами», автор Николас Руссель.
Поскольку система полностью контролирует окружение всех приложений, она может принудительно ввести ограничения безопасности и демонстрировать это пользователю. Например, у доверенных приложений могут быть зелёные рамки. У только что скачанного из интернета нового приложения будет красная рамка. У приложения неизвестного происхождения — чёрная рамка, или оно вообще не выводится на экран. Многие виды спуфинга станут невозможными.
»» Нажмите, для закрытия спойлера | Press to close the spoiler «« Умный копипаст» Нажмите, для открытия спойлера | Press to open the spoiler «
Когда вы скопировали текст из одного окна и переключились в другое, компьютер знает, что вы что-то скопировали. Он может использовать это знание для осуществления каких-нибудь полезных действий, например, автоматически сдвинуть первое окно в сторону, оставив его в зоне видимости, и отобразить выделенный текст зелёным цветом. Это помогает пользователю сохранить концентрацию на текущей задаче. Когда пользователь вставляет текст в новом окне, можно показать, как зелёный фрагмент перепрыгивает из одного окна в другое.
Но зачем ограничивать себя этим. Сделаем буфер обмена, который вмещает больше одного элемента. У нас гигабайты памяти. Давайте использовать её. Когда я копирую что-то, почему я должен помнить, что конкретно я копировал перед тем, как вставить это в другом окне? Буфер обмена нигде не видим. Исправим это.
Буфер обмена должен отображаться на экране как некая полка, на которой хранятся все скопированные фрагменты. Я могу зайти на три веб-страницы, скопировать их адреса в буфер обмена, а затем вернуться в документ и вставить все три сразу.
Модуль просмотра буфера обмена позволяет прокручивать всю историю буфера. Я могу искать в ней и фильтровать по тегам. Могу «прикрепить» любимые экземпляры для последующего использования.
В классической macOS на самом деле был отличный встроенный инструмент под названием [name], но от него отказались при переходе на OS X. Десятилетия назад у нас было будущее! Вернём его обратно.
»» Нажмите, для закрытия спойлера | Press to close the spoiler «« Рабочие наборы» Нажмите, для открытия спойлера | Press to open the spoiler «
И наконец-то мы переходим к тому, что я считаю самым мощным изменением парадигмы в нашей новой Идеальной ОС. В новой системе все приложения представляют собой крошечные изолированные модули, которые знают только то, что говорит им система. Если расценивать БД как единственный источник правды, а сама БД версионированная, а наш оконный менеджер настраивается на любой вкус… то становятся возможными по-настоящему интересные вещи.
Обычно я разделяю личные и рабочие файлы. Это отдельные папки, аккаунты, иногда разные компьютеры. В Идеальной ОС мои файлы могут разделяться средствами самой ОС. У меня может быть один экран с домашней почтой, а другой экран — с рабочей. Это одно и то же приложение, просто инициализированное с разными настройками запросов.
Когда я открываю файл-менеджер на домашнем экране, то он показывает только файлы, предназначенные для домашних проектов. Если я создаю документ на рабочем экране, то он автоматически помечается тегом как строго рабочий документ. Управление всем этим тривиально; просто несколько дополнительных полей в базе данных.
Исследователи из Технологического института Джорджии в реальности описали такую систему в своей научной работе «Giornata: пересмотр метафоры десктопа для содействия высококвалифицированной работе»
Теперь сделаем ещё один шаг. Если всё версионируется, даже настройки GUI и расположение окон (поскольку всё хранится в БД), я могу сохранить состояние экрана. Он будет хранить текущее состояние всех параметров, даже мои сочетания клавиш. Я могу продолжить работу, но всегда будет возможность вернуться к этому состоянию. Или я могу посмотреть старое состояние — и восстановить его на новом экране. Я по сути создал «шаблон», который можно использовать снова и снова, как только я начинаю новый проект. Этот шаблон содержит всё необходимое: настройки почтового клиента, историю чатов, списки дел, код, окна для описания багов или даже соответствующие страницы Github.
Теперь всё состояние компьютера в сущности рассматривается как репозиторий Github, с возможностью форкнуть состояние целой системы. Думаю, это будет просто волшебно. Люди станут обмениваться полезными рабочими пространствами в онлайне, как образами Docker. Можно настраивать свои рабочие процессы, добавлять полезные скрипты к рабочему пространству. Возможности здесь поистине восхитительные.
»» Нажмите, для закрытия спойлера | Press to close the spoiler «« Ничего из этого не ново» Нажмите, для открытия спойлера | Press to open the spoiler «
Так что вот так. Мечта. Всё вышеописанное базируется на трёх принципах: всесистемная версионированная база данных в реальном времени, всесистемная шина сообщений в реальном времени и программируемый компоновщик.
Хочу подчеркнуть, что абсолютно ничего из того, о чём я рассказывал, не является новым. Я ничего не придумал. Всем этим идеям годы или десятилетия. Файловые базы данных впервые появились в BeOS. Единый механизм межпроцессных взаимодействий появился в Plan 9. Настройка окружения из редактируемого документа реализована в Oberon. И конечно ещё огромное множество научных статей с результатами исследований.
»» Нажмите, для закрытия спойлера | Press to close the spoiler «« Почему у нас этого нет?» Нажмите, для открытия спойлера | Press to open the spoiler «
Здесь ничего нового. И у нас до сих пор этого нет? Почему так?
Подозреваю, что главная причина просто в сложности разработки успешной операционной системы. Гораздо удобнее расширять существующую систему, чем создать нечто новое; но расширение также означает, что вы ограничены выбором, сделанным в прошлом.
Можем ли мы в реальности создать Идеальную ОС? Подозреваю, что нет. Никто не сделал это до сих пор, потому что, если честно, здесь не заработаешь деньги. А без денег просто не найдёшь ресурсы для разработки.
Однако если кто-то всё-таки поставит цель создать такую ОС или хотя бы рабочий прототип, то я бы начал с конкретного ограниченного набора аппаратного обеспечения с существующими драйверами устройств. Недостаточная поддержка драйверов всегда была ахиллесовой пятой десктопного Linux. Например, Raspberry Pi 3 будет отличным вариантом.
Так что мой вопрос к вам: как вы думаете, идея стоит усилий на её реализацию, хотя бы для создания рабочего прототипа? Вы бы поучаствовали в таком проекте? Какая часть функциональности должна работать, чтобы вы согласились взять систему для тестирования? И конечно, как нам её назвать?
Если вам интересно обсуждение будущего десктопного UX, подписывайтесь на нашу новую группу Ideal OS Design.
»» Нажмите, для закрытия спойлера | Press to close the spoiler «« Источник: geektimes, первоисточник
Цитата | Quote(AquaTour @ 4.09.2017 - 3:28)
Автор - типичный нытик, если посадить его в описанные им же "идеальные условия" станет ныть еще громче о том, как было хорошо раньше.
Автор - не нытик-потребитель контента, автор -
- активный разработчик ПО, с незашоренным мышлением